It looks perfect. Although my only concern is if we should use the preposition “in” (since the year comes first: “in 2024”) or “on” (because we say “on January 24”).
It’s great when organizing something in a database. You can just do A to Z ordering and it works just fine.
However visually it’s not very good because it puts the least important piece of information first and the most important piece of information last. I probably know the current year so it doesn’t need to be that prominent, and I’m fairly certain that it’s going to be sometime this millennium, so I don’t need the date to four digits.
It’s entirely depend on the time frame range of your data. If it’s wide it rapidly becomes useful to see the year first. In general I like to put ‘larger’ group variables in tables from left to right, helps in a similar way.
ISO-8601 or bust.
I prefer RFC 3339. It allows you to omit the “T” for example. Like this: 1985-04-12 23:20:50Z
Either is preferable to the abomination in the meme.
Imo, the more strict the format the better. Less ambiguity == less confusing when it doesn’t work and easier parser to write.
Today is 2024, January 24.
It looks perfect. Although my only concern is if we should use the preposition “in” (since the year comes first: “in 2024”) or “on” (because we say “on January 24”).
It’s great when organizing something in a database. You can just do A to Z ordering and it works just fine.
However visually it’s not very good because it puts the least important piece of information first and the most important piece of information last. I probably know the current year so it doesn’t need to be that prominent, and I’m fairly certain that it’s going to be sometime this millennium, so I don’t need the date to four digits.
It’s entirely depend on the time frame range of your data. If it’s wide it rapidly becomes useful to see the year first. In general I like to put ‘larger’ group variables in tables from left to right, helps in a similar way.
Removed by mod