The dates should be numerical, ordered and include the complete data. This makes it possible for humans and machines to parse it with minimal thought on the format.
There is no case to be made for using a single regional format globally when the regional format fails on all the required fronts.
The YYYY-MM-DD HH:MM:SS format can be parsed by anyone because it cannot be misinterpreted. It may not be the regional one but it is unambiguous. It contains all the data and humans and machines are both able to ignore data that is not needed while they cannot extrapolate data that is not there. Stripping leading centuries makes sorting ambiguous, removing leading zeroes makes human tabulation and simple text sorting fail. Transposing the digit significance destroys any semblance of data management and makes simple sorting fail. Using natural language month names or contractions of them is a slap in the face of ALL non native language users who have to use mental bandwidth to determine the actual date. English natives would struggle with month names from almost any other language but the reverse affects even more people.
Please default to the best and let users style as desired if so desired.
9 Likes
Agreeable. Confusion with date/time is something very easy to avoid, though are we using local timezones or not?
Generally speaking, this is the best policy. To clarify a bit more:
- ISO 8601 UTC as default - MVP.
- Same basic format but local time zone should be MVP. Not sure of the best way to determine local time zone - options include:
- User Profile (this is what I usually do, but most of my customers are single-time-zone)
- Some sort of client/browser-based determination (I know there are ways to do this, but not sure how)
- Alternative preferred regional format, set in User Profile - e.g., MM/DD/YYYY instead of YYYY/MM/DD for US, AM/PM vs. 24-hour, etc. Not MVP.
I would also like to have full date/time stamps shown even when a relative time like “20 minutes ago” or “3 hours ago” or “yesterday” is shown. Those relative values are helpful in many cases. But there are many times when seeing the exact timestamp would be helpful too. SE does this with mouseover, but that requires an extra step (annoying to do that on every line when trying to scan through a bunch of comments) and also doesn’t work on all devices (e.g., many smartphones). I know graphic designers don’t like it because it doesn’t add much information and clutters the page - well, those graphic designers aren’t the ones actually trying to use the site and read the page and immediately get the information they need, which includes not having to mouseover or do extra work of mentally comparing different date formats, etc.
3 Likes
Localizing timestamps is actually a very easy one to do client-side: new Date().toLocaleTimeString() will get you a correctly-formatted string for the current locale.
2 Likes
The hard part is not doing the formatting. It is deciding what the locale should be. I’m skeptical as to whether the actual Javascript default is necessarily what the user wants. Plus that works for pure client side display. It doesn’t work for build a PDF server side or for email communication with users. So I recommend a profile setting.
1 Like