I typically write user-visible dates as “26 Feb 2021”: this way it’s always clear for pretty much anyone who can speak English (and also many who don’t, since month names tend to be very similar across languages). You could argue that “2021-02-26” is better, but many people aren’t used to it so I don’t think it’s very user-friendly.
For databases and other technical (non-user visible) there is no discussion that ISO 8601(-ish) dates formatted as “2021-02-25” is the only acceptable format.
This is also why I often use (thin) spaces for thousands separators by the way: “64 737” instead of “64,737”.
Same, but I wonder if that’s because I’m in the US where everyone expects the month to come before the day anyway. I’m moving the year to the beginning but otherwise it is a normal human-readable date. Does it go over as well in countries that use DD/MM dates normally?
Always has for me! (Australia.) I think people here are more sensitive to different date formats, given we use the less popular of the two and everyone’s online.
I do the same when communicating professionally. We use English mostly and I tend to refer to dates as “26 Feb 2021 12:00 CET (UTC+1)” because spending a couple of seconds writing usually saves hours of confusion when scheduling meetings etc.
How do you output thin spaces? It’s part of Swedish typographical standard to use for thousands separators but it’s a pain online because of bad support for thin spaces (that also have to be non-breaking).
I think they render pretty much identical, although this depends on the font. The advantage of the non-breaking space is that it shouldn’t be used as a line-break: https://imgur.com/a/tbVnamc
Neither is “more correct”, in English at least, and using just a thin space is fine too, but I think the first looks a bit nicer.
It’s part of Swedish typographical standard to use for thousands separators but it’s a pain online because of bad support for thin spaces (that also have to be non-breaking).
I thought the thousands separator was just a non-breaking space, not a thin non-breaking space.
OK, so I tried to implement this on my blog, with an idea of adding a filter so that I could use commas as thousands separators in Markdown, then they would be replaced by non-breaking thin spaces during rendering.
But while it works in the main matter, it does not work in headings for some reason.
For databases and other technical (non-user visible) there is no discussion that ISO 8601(-ish) dates formatted as “2021-02-25” is the only acceptable format.
Depending on application, unix timestamp may also be the way to go.
Then you implement a lookup table with historical leapseconds, and use that to display the current UTC time.
If you are ambitious, you can amend the lookup table as soon as a new leapsecond is announced.
The point is that from the point of view of your code (or database), there’s only a monotonical increase of seconds. You effectively treat the difference between TAI and UTC as a sort of timezone.
Of course, to be really useful, each clock in your system that emits events needs to use TAI (or some other time scale without leap seconds, like GPS time). Then it’s up to the user-facing interface to translate to civil time.
I wish I could summarize the meaning of “profile” in a way that would be clear or at least helpful. For now, I’ll just share one key sentence:
A Profile of ISO 8601 is a specification developed by a particular community which explains how ISO 8601 is to be used, to carry out a particular function or group of functions relevant to that community.
Hopefully my Gist above will save you some time if you have some bizarre desire to investigate further.
This should be the top comment; in normal usage, people really mean RFC3339 and not the full monty of ISO8601. Writing a parser for that is a deal easier than supporting, say, periods or durations.
A number of devices currently connected to the Internet run their
internal clocks in local time and are unaware of UTC. While the
Internet does have a tradition of accepting reality when creating
specifications, this should not be done at the expense of
interoperability. Since interpretation of an unqualified local time
zone will fail in approximately 23/24 of the globe, the
interoperability problems of unqualified local time are deemed
unacceptable for the Internet. Systems that are configured with a
local time, are unaware of the corresponding UTC offset, and depend
on time synchronization with other Internet systems, MUST use a
mechanism that ensures correct synchronization with UTC. Some
suitable mechanisms are: …
If you’re smart enough, you’ve probably also noticed that the American one makes no sense and is just awful.
but for clarity, the reason it’s month-day-year is because most Americans say “January 2nd, 2012” as an example, not “2 January” or “the 2nd of January” or whatever else. The date format follows how we say it rather than size of the time unit.
I personally use yyyy-mm-dd because it’s more clear to me and I deal with international folks, but I don’t think the general American way is stupid or wrong either.
According to Wikipedia, “Separating date and time parts with other characters such as space is not allowed in ISO 8601”, so the core date format would be not yyyy-mm-dd hh:mm:ss, but yyyy-mm-ddThh:mm:ss.
However, the profile defined in RFC 3339 allows the space: “NOTE: ISO 8601 defines date and time separated by “T”. Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.”
I find the idea of a single “European” date format funny. There must be at least a dozen different formats used from country to country and language to language, although to be fair they are mostly day, month, year.
I don’t defend the American date shorthand format on any grounds other than that it’s what I’ve used all my life. I agree that in any kind of programming context or any context where people from outside the US might see it, you should go with the unambiguous and standardized ISO 8601 date representation. But I’m not gonna stop scrawling 2/26/21 when I need to date a check or something, Europeans be damned (also don’t Europeans no longer use checks? that’s another American thing I don’t defend).
I think it’s interesting that checks are still used the US, it’s so… antique. Last time I saw a check was the single time in several years I worked in a game store in the early 00s that someone wanted to pay using one. It took us a while to figure out if we accepted checks and how to handle it.
In Sweden we’ve since gone one step further and basically no longer use cash. My guess is that it’s mostly 90+ year olds who still use it, and maybe allowances for kids under 7 who can’t have their own Mastercard and Swish.
There’s a fair chance that this is something we’ll regret at one point, but we’ll see… very convenient until that day comes, at least!
Another thing I really like about ISO 8601 that isn’t mentioned in the article is that it supports time zones. This way you can always convert a time to whatever local timezone you or your users are currently in. I.e. 2021-02-25T19:19:55+01:00 has an offset of UTC + 1 hour.
Because there are 3 circular orbits, I feel like a symbolic language for time that resembles polar coordinates might be better. In the age of emojis something like that might be possible now.
Personally, my favorite date format (for paper, not programs) is D/M Y, which Y being optional. Today, for instance, is 26/2. It’s great not having to specify the year, but it still being clear (at least where I live) that it is a date.
What really annoys me is how everybody has gone over to writing stuff like “25 hours ago” instead of the time and date of the comment or post. Am I the only one?
It is important to consider the purpose. While mm/dd/yyyy format is probably always bad. The dd. mm. yyyy is often preferred as a human-readable format (printed on papers, shows on screens etc.). And yyyy-mm-dd is a good machine-readable format (in log files, in fields in a text data format or protocol etc.).
The technical merits of the ISO 8601 scheme over either of the ambiguous and unsortable schemes in popular use is hard to argue with. On the other hand having those merits presented under pink Comic Sans headings on a green background with a 90’s tiled GIF wallpaper makes the pill a bit hard to swallow.
My favorite aspect (mentioned in the article) is that files that use this (logs, whatever) automatically sort sensibly!
Only until we get to year 10000. :-(
I vote that when that happens, we change the first digit of the year to hexadecimal so we can put off figuring out a real fix until the year 16000.
At that point we switch to ISO 08601
The Long Now Foundation hasn’t tried to update the ISO standard (that I’m aware of), but they’ve been using 5 digit years for a while now.
There’s already a solution for that: RFC2550
Or, in a “a picture’s worth a thousand words” format: https://xkcd.com/1179/
Or recently on Twitter referring to this Reddit posting (deleted already by moderators, still accessible, though).
I typically write user-visible dates as “26 Feb 2021”: this way it’s always clear for pretty much anyone who can speak English (and also many who don’t, since month names tend to be very similar across languages). You could argue that “2021-02-26” is better, but many people aren’t used to it so I don’t think it’s very user-friendly.
For databases and other technical (non-user visible) there is no discussion that ISO 8601(-ish) dates formatted as “2021-02-25” is the only acceptable format.
This is also why I often use (thin) spaces for thousands separators by the way: “64 737” instead of “64,737”.
I’m using ISO8601 whenever i have to sign something. Never had any complaints or problems.
Same, but I wonder if that’s because I’m in the US where everyone expects the month to come before the day anyway. I’m moving the year to the beginning but otherwise it is a normal human-readable date. Does it go over as well in countries that use DD/MM dates normally?
Always has for me! (Australia.) I think people here are more sensitive to different date formats, given we use the less popular of the two and everyone’s online.
I do the same when communicating professionally. We use English mostly and I tend to refer to dates as “26 Feb 2021 12:00 CET (UTC+1)” because spending a couple of seconds writing usually saves hours of confusion when scheduling meetings etc.
How do you output thin spaces? It’s part of Swedish typographical standard to use for thousands separators but it’s a pain online because of bad support for thin spaces (that also have to be non-breaking).
I have it set up in XCompose:
So pressing right alt + space + space will insert U+202F.
I have this:
Is U202F a thin space too?
I think they render pretty much identical, although this depends on the font. The advantage of the non-breaking space is that it shouldn’t be used as a line-break: https://imgur.com/a/tbVnamc
Neither is “more correct”, in English at least, and using just a thin space is fine too, but I think the first looks a bit nicer.
I thought the thousands separator was just a non-breaking space, not a thin non-breaking space.
No, it’s a thin one. Source: Typografisk handbok.
Huh – thanks for the tip. Just made my life a tiny bit harder… :-)
You only have to care when typesetting professionally. The web is a lost cause.
It’s kind of been a lost cause ever since the printing press was invented 🙃 I don’t think simplification is necessarily a bad thing though.
OK, so I tried to implement this on my blog, with an idea of adding a filter so that I could use commas as thousands separators in Markdown, then they would be replaced by non-breaking thin spaces during rendering.
But while it works in the main matter, it does not work in headings for some reason.
My approach is that they will have to deal with it.
“26 Feb 2021” is often recommended or even required, to avoid confusion between dd/mm/yyyy and mm/dd/yyyy when dealing with cases across borders.
Depending on application, unix timestamp may also be the way to go.
Unix timestamps is the worst of both worlds - not human readable and affected by leap seconds.
Use TAI timestamps instead.
Except usually I want leap seconds in there so my time isn’t wrong?
Then you implement a lookup table with historical leapseconds, and use that to display the current UTC time.
If you are ambitious, you can amend the lookup table as soon as a new leapsecond is announced.
The point is that from the point of view of your code (or database), there’s only a monotonical increase of seconds. You effectively treat the difference between TAI and UTC as a sort of timezone.
Of course, to be really useful, each clock in your system that emits events needs to use TAI (or some other time scale without leap seconds, like GPS time). Then it’s up to the user-facing interface to translate to civil time.
“thin spaces” has really made me stop and wonder…
Unicode has spaces for many tastes - http://jkorpela.fi/chars/spaces.html
I like the idea of “taste” in a field so normally strict. I should look for more of that sort of thing…
There is also RFC 3339 which is a profile of ISO 8601.
I’ve found it difficult to find the authoritative definition of what “profile” means. So I created this Gist: https://gist.github.com/xpe/22dbf6920ffa0dd9328c74fb622f03f5
I wish I could summarize the meaning of “profile” in a way that would be clear or at least helpful. For now, I’ll just share one key sentence:
Hopefully my Gist above will save you some time if you have some bizarre desire to investigate further.
This should be the top comment; in normal usage, people really mean RFC3339 and not the full monty of ISO8601. Writing a parser for that is a deal easier than supporting, say, periods or durations.
Yes, not to mention that reading RFC 3339 can be … (dare I say) fun?. For example, here is a fun quip from https://tools.ietf.org/html/rfc3339#page-4 :
I added the bold text.
Plus, when I see year as the first element I immediately know it’s this format.
I’m sure this is tongue-in-cheek:
but for clarity, the reason it’s month-day-year is because most Americans say “January 2nd, 2012” as an example, not “2 January” or “the 2nd of January” or whatever else. The date format follows how we say it rather than size of the time unit.
I personally use yyyy-mm-dd because it’s more clear to me and I deal with international folks, but I don’t think the general American way is stupid or wrong either.
That’s interesting. Do Americans say “$2” as “dollar two”?
In the UK I pronounce “14:00” as “two PM”, “£2” as “two pounds”, and “2021-02-28” as “tomorrow”.
No, but a depressingly large number of us write it as “$2 dollars.”
No but I have seen a ton of people write it as “2$” instead of “$2” because of that.
According to Wikipedia, “Separating date and time parts with other characters such as space is not allowed in ISO 8601”, so the core date format would be not yyyy-mm-dd hh:mm:ss, but yyyy-mm-ddThh:mm:ss.
However, the profile defined in RFC 3339 allows the space: “NOTE: ISO 8601 defines date and time separated by “T”. Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.”
Is there actually a debate about not using DateTime strings in that format? Everyone I have encountered this is good practice.
I find the idea of a single “European” date format funny. There must be at least a dozen different formats used from country to country and language to language, although to be fair they are mostly day, month, year.
Yes please. I wrote a longer treatise about this a while ago.
That said, I agree with @arp242 that user-visible names should be represented in a more friendly format.
I don’t defend the American date shorthand format on any grounds other than that it’s what I’ve used all my life. I agree that in any kind of programming context or any context where people from outside the US might see it, you should go with the unambiguous and standardized ISO 8601 date representation. But I’m not gonna stop scrawling 2/26/21 when I need to date a check or something, Europeans be damned (also don’t Europeans no longer use checks? that’s another American thing I don’t defend).
I think it’s interesting that checks are still used the US, it’s so… antique. Last time I saw a check was the single time in several years I worked in a game store in the early 00s that someone wanted to pay using one. It took us a while to figure out if we accepted checks and how to handle it.
In Sweden we’ve since gone one step further and basically no longer use cash. My guess is that it’s mostly 90+ year olds who still use it, and maybe allowances for kids under 7 who can’t have their own Mastercard and Swish.
There’s a fair chance that this is something we’ll regret at one point, but we’ll see… very convenient until that day comes, at least!
Another thing I really like about ISO 8601 that isn’t mentioned in the article is that it supports time zones. This way you can always convert a time to whatever local timezone you or your users are currently in. I.e. 2021-02-25T19:19:55+01:00 has an offset of UTC + 1 hour.
Because there are 3 circular orbits, I feel like a symbolic language for time that resembles polar coordinates might be better. In the age of emojis something like that might be possible now.
Personally, my favorite date format (for paper, not programs) is D/M Y, which Y being optional. Today, for instance, is 26/2. It’s great not having to specify the year, but it still being clear (at least where I live) that it is a date.
A week from now it will be 5/3 and this will be a much harder sell. If I see 5/3, I have no idea whether it’s M/D or D/M.
Yeah, but as I said, it depends on where you live. In Sweden, this format is common and widely recognized. Nobody would interpret it as M/D.
Here is an interesting point (not present in the original posting):
source: http://www.uic.edu/depts/accc/software/isodates/datefmt.html
What really annoys me is how everybody has gone over to writing stuff like “25 hours ago” instead of the time and date of the comment or post. Am I the only one?
At least this site (and me, where appropriate) has the full timestamp (in RFC 3339 format) visible as a tooltip if you hover over it.
I’m kinda torn, I prefer relative times up until ~1 month but absolute datetimes after that.
It is important to consider the purpose. While
mm/dd/yyyyformat is probably always bad. Thedd. mm. yyyyis often preferred as a human-readable format (printed on papers, shows on screens etc.). Andyyyy-mm-ddis a good machine-readable format (in log files, in fields in a text data format or protocol etc.).Paging @cadey on this day, M02 27 2021.
The technical merits of the ISO 8601 scheme over either of the ambiguous and unsortable schemes in popular use is hard to argue with. On the other hand having those merits presented under pink Comic Sans headings on a green background with a 90’s tiled GIF wallpaper makes the pill a bit hard to swallow.
Is it wrong of me to consider popularising a YYYY-DD-MM format to remove the unambiguity?
It could be called “lobster format” to maximally offend.
Please don’t.