41 ms·

ISO 8601: a better date format

367 points by kirbykevinson 6y ago

kitd 6y ago
The real purpose of endianness which is missed here is the ability to sort. Sorting a list of iso8601 dates alphabetically means sorting them chronologically too.
- deleted 6y ago
  [deleted]
- k_sze 6y ago
  Until we hit year 10000, but yeah, that's still a looong time to go.
  - est 6y ago
    There's some proposal that this year 2021 is actually 12021, to make the year neutral of some specific religious event.
    - ComputerGuru 6y ago
      I know you’re not saying you are encouraging it and it’s just a related but of trivia, but I find that hilarious. Because when someone asks “why start there?” the answer “it’s a thousand years before Jesus Christ was born, the millennium heralding his arrival” is better? (I’m not even Christian but I also don’t have a chip on my shoulder and can accept its influence on the world)
      - bhaak 6y ago
        It's ten thousand years before the assumed (but likely wrong) birthday of Jesus Christ, to have a positive date for all written human history (well, until we find the archives of Atlantis) and an easy round offset for the prevalent human calender in use.
      - grey_earthling 6y ago
        The answer is “because -10000 CE is an approximation of the beginning of human civilisation, using this epoch removes negative year numbers from all historical dates, and it's simple to convert from the ubiquitous CE epoch”. https://en.wikipedia.org/wiki/Holocene_calendar https://en.wikipedia.org/wiki/Holocene_calendar
    - mattashii 6y ago
      ... which is funny, because the gregorian calendar is supposedly based on a compromise between some years that christ was supposedly born in (the chosen year 1 is none of those, according to research, as he was born in 6-4 BC [0]). So now we have: another calendar, that has a starting year that is defined by subtracting an arbitrary number from a compromise between alledged years some person was born in. I love how humanity has the capability to invent new things with increasing complexity. [0] https://en.wikipedia.org/wiki/Anno_Domini#Birth_date_of_Jesus https://en.wikipedia.org/wiki/Anno_Domini#Birth_date_of_Jesu...
    - TeMPOraL 6y ago
      Yup. I have a calendar for 12021 hanging in my office, and I very like the sentiment it expresses. I tried to use the Holocene years with other people, but they remain unconvinced.
- eesmith 6y ago
  It's there: > This not only makes all of the dates look equally nice, but also, coupled with other quirks of this format, allows the files with the date in the name to be sorted just by the filename. My issue is with: > Simplified, the core date format looks like this: yyyy-mm-dd hh:mm:ss Here are the examples at https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601 2021-02-26T06:22:59+00:00 2021-02-26T06:22:59Z 20210226T062259Z Note the "T" instead of a space between the date and time? That's what the spec says: https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_tim... . "Separating date and time parts with other characters such as space is not allowed in ISO 8601, but allowed in its profile RFC 3339." Note the optional use of "-" and ":"? That's "basic" vs. "extended" formats. Plus the optional timezone specifier (if not present, assume it's the same timezone). There's also optional support for microseconds.
  - kirbykevinson 6y ago
    I omitted this detail on purpose to not distract the reader who doesn't know much about date formats.
    - eesmith 6y ago
      How would you describe the accuracy and veracity of > "Here there’s only one correct way to write a date," given that there are multiple correct ways, and the way shown wasn't actually ISO 8601 but RFC 3339?
      - kirbykevinson 6y ago
        Yes, technically there are some edge cases where you can write things differently (apart from what you mentioned, one is, for example, writing the UTC time zone by Z vs +00:00 and another is adding additional precision to the date), but for the end user it's basically the same. Let's not ruin the illusion here :)
        eesmith 6y ago
- mjevans 6y ago
  That's also the only time (full) European dates make sense, when writing them on the right hand side of a ledger page so that the exterior of the ledger / book is indexed with the largest components on the edge of the page. US dates only make sense if you don't care about the year and are writing on the left most side of a page; that might make sense if ink or paper is at a premium.
  - orwin 6y ago
    My great great grandfather wrote a book about this 120 years ago! And yes, it was for taxes and accounting.
  - nayuki 6y ago
    What you said about European dates (e.g. 27/02/2021 today) is not strictly true. The rightmost character is the ones digit of the year, and it is not the largest component. According to your rules, 01/01/2019 would be "larger" than 01/01/2021 because 9 is larger than 1. The blog post already made this observation, saying that YMD is the only format where the endianness of the date components match the endianness of the numbers; DMY does not have this property. If you wanted to sort dates correctly on the right hand side, you need to write the numbers backwards too, like "72/20/1202".
k_sze 6y ago
I teach my 9-yo daughter to write dates in ISO 8601 format whenever permissible, too. I tell her that all other formats that her school teaches her are just nonsense and wrong.
- fouronnes3 6y ago
  Is her middle name \";DROP TABLE users;?
- deleted 6y ago
  [deleted]
- codeful 6y ago
  this is responsible and good parenting! thumbs up
- euroderf 6y ago
  Raise her on hexadecimal too. She will thrive.
  - k_sze 6y ago
    Now now, let’s not put the cart before the horse. Binary first, and then boolean logic, and then automata theory, and then...
jiggawatts 6y ago
The real advantage is that Azure and AWS and every other US-centric cloud service insists on showing me that something happened on the 3/11/2021. It's a wild guess to figure out if that is the 11th of March or the 3rd of November. Unless there's also another date with a number higher than 12 in it, there is no way to tell. None. None whatsoever. For US staff with US regional settings, it's always obvious which date is correct. That is the one single case where there is no confusion. This works as expected for just 4% of the world population, but it is those 4% of the world that get to decide the date format. It's the most obnoxiously American attitude imaginable to ignore this issue because it doesn't affect them... only the other 96% of the planet. /rant over
- vbezhenar 6y ago
  It took many decades to widely adopt UTF-8. I think that one of the reasons was that US companies did not really care about character encodings, as it's not something they have to often deal with. Even today managing multiple keyboard layouts is a pain in most operating systems, it's buggy, it does not have enough configuration options, it's not convenient. Probably because most US developers never tried to use that functionality.
  - jacobolus 6y ago
    Mac Firefox and Mac Chrome both break a bunch of keyboard shortcuts if you use a non-US-ANSI keyboard. Safari handles alternate layouts correctly. Just yesterday I learned that on an ISO Spanish keyboard, both of those browsers will pop up a help menu for ⌘⇧7. The logic goes: ⇧7 means / on a Spanish ISO keyboard, and ⇧/ means ? on a US-ANSI keyboard, therefore ⌘⇧7 is by the transitive property of inter-layout shift functions equivalent to ⌘?, which is the shortcut for opening the help menu. They don't pop open the help menu if you press ⌘⇧', the actual ISO Spanish layout way to type ⌘?
    - misterS 6y ago
      Stuff like this is the reason why I, as a non-american software engineer, use `US_en` layouts on all my machines.
rchaves 6y ago
yyyy-mm-dd is so nice you can just work with strings for your date stuff, converting to objects and back is tedious Shameless plug: I built a python library to do exactly that https://pypi.org/project/yyyy-mm-dd/ https://pypi.org/project/yyyy-mm-dd/
- grenoire 6y ago
  Quite nifty and clean; I think this could play well with support for the duration (P-Y-M-D...) format in ISO 8601 that declares a positive offset. https://en.wikipedia.org/wiki/ISO_8601#Durations https://en.wikipedia.org/wiki/ISO_8601#Durations
  - akavel 6y ago
    Interesting, didn't know about that! Do you know of some canonical way of expressing negative offsets in spirit of ISO 8601? I don't seem to see those mentioned in the article...
    - grenoire 6y ago
      Unfortunately not, for the project I'm working on right now I only needed 'forward' durations. There's a W3C extension that proposes a preceding - sign for negative durations, which I think it's fair https://www.w3.org/TR/xmlschema-2/#duration https://www.w3.org/TR/xmlschema-2/#duration. The ISO standard explicitly declares durations to be non-negative, on the other hand. As close to canonical as you can get.
    - rswail 6y ago
      You can specify an interval as start/duration, start/end, or duration/end. So you could specify a negative offset as a duration and the end time. P2H/2021-02-26T13:30Z is two hours prior or T11:30Z on the same date.
- globular-toast 6y ago
  It's not tedious if you do it right. All of your conversions should be done in your I/O layer and nowhere else. For many applications that means there's a single place to do it. Hardly tedious. I notice that your library is targeted at notebooks, though. It seems useful in that context, but not for general programming.
hannob 6y ago
There's another aspect you may not know about: It's close to how it's done in chinese, which is 2021年3月17日. They use different separators (the chinese words for year, month and day), but it's close enough. Given that china is the country with the largest population it may not be a bad idea to use something a large number of people will easily understand.
- CyberRabbi 6y ago
  Maybe we should also start speaking Chinese since it may not be a bad idea to use something a large number of people will easily understand. Edit: this is not sarcasm. It’s simple logic, unless there is something wrong with learning other languages.
  - monsieurbanana 6y ago
    Sigh... I never remember the names of the logical fallacies, I have to look up them, thanks a lot. Anyways, here's yours: Slippery Slope.
    - CyberRabbi 6y ago
      Where’s the logical fallacy? More people natively speak Chinese than any other language in the world. If you want to maximize the exposure of your ideas, it’s only logical to render them in Chinese. It’s the same reason I prefer to distribute applications over the web. FYI: English has ~1100 million total speakers but only 318 millon native speakers, while Chinese has 918 million native speakers. https://www.visualcapitalist.com/100-most-spoken-languages/ https://www.visualcapitalist.com/100-most-spoken-languages/
      - dataflow 6y ago
        https://www.statista.com/statistics/266808/the-most-spoken-languages-worldwide/ https://www.statista.com/statistics/266808/the-most-spoken-l... Unless it's already out of date...
      - 6y ago
atoav 6y ago
As a european I use ISO 8601 for everything since about 5 years. One point is also: if you manually write a date, the easiest to remember part (the year) comes first, then the month (which is usually also easily remembered) and then the thing that you can forget at times. This feels better than the other way around.
- JdeBP 6y ago
  I can beat that slightly. I have things with ISO 8601 dates written on them, by me, dating from 1986. Yes, I started using it before it was formally published as a standard. I initially used the basic format.
tpetry 6y ago
The article is missing one of the best features of iso 8601: it‘s string form is naturally sortable. You don‘t need any specific logic for sorting, so e.g. your filesystem will automatically sort files correctly if you prefix them with a iso 8601 date.
- Someone 6y ago
  FTA: “The elements are always padded to the maximum number of digits. This not only makes all of the dates look equally nice, but also, coupled with other quirks of this format, allows the files with the date in the name to be sorted just by the filename.”
- m12k 6y ago
  Which is a side effect of being consistent with the way we write all other numbers, with the value represented by each digit declining as we go left to right.
  - jeff-davis 6y ago
    Lexicographic sorting does not work for numbers of different lengths, e.g. "100" and "9".
    - pwg 6y ago
      It does if you zero fill the shorter number to an equal number of digits: "100", "009".
      - koolba 6y ago
        There's a special place in hell for people that using variable length representations for time units that are meant to be consumed by machines. I think it's across the hall from the room for people who configure servers for anything besides UTC.
        JdeBP 6y ago
wodenokoto 6y ago
People look at ISO-8601 and think year-month-day looks great! But don’t realize that it also includes thing like —month-day (yes, you don’t need to include year to have a valid iso date!) year-week, year-day and lots of other things. So I would generally advise against accepting iso formatted dates and instead decree a single date format. https://en.m.wikipedia.org/wiki/ISO_8601 https://en.m.wikipedia.org/wiki/ISO_8601
- tuukkah 6y ago
  > The 2000 version allowed writing "--04-05" to mean "April 5"[23] but the 2004 version does not allow omitting the year when a month is present.
makach 6y ago
It's time to come clean, I love you ISO8601 and I always have. You complete me.
rollulus 6y ago
At the risk of nitpicking, I prefer RFC 3339, which is a profile of ISO 8601. ISO 8601 provides room for things you typically don't want, e.g. dropping time zone offsets. While I'm typing this I realise that I've never actually read the ISO 8601 spec, like probably most people here, because it's not free. I cannot even be sure it really exists.
- SideburnsOfDoom 6y ago
  > I've never actually read the ISO 8601 spec, like probably most people here Indeed. The comprehensive Wikipedia article on ISO8601 is as far as we go https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601 Thanks for pointing out rfc3339 - this appears to be the "useful part" of ISO8601 for data interchange. https://tools.ietf.org/html/rfc3339 https://tools.ietf.org/html/rfc3339
  - wongarsu 6y ago
    Draft versions of the ISO standard are easy enough to find on the internet. But the Wikipedia article is excellent and covers just about everything.
    - diggernet 6y ago
      Yes, and I've read the drafts of ISO 8601-1:2019 and 8601-2:2019. But can I rely on them? They were published in 2016. What has changed between then and the official release in 2019? Also, neither RFC3339 nor Wikipedia discuss features like open-ended time intervals. They are in the draft, but did they make the final cut? And in what form? No idea... The closest I've found to "official" documentation of the 2019 update is a short summary of the changes, hosted by Library of Congress[1]. Which is nice to have, but I sure wish the real standard was public. [1]https://www.loc.gov/standards/datetime/ https://www.loc.gov/standards/datetime/
- CuriousNinja 6y ago
  > never actually read the ISO 8601 spec ... because it's not free I was very surprised to discover this. Why are they charging money for the specification of a date format? I would expect standards like these to be published in public domain.
systemvoltage 6y ago
No one here is talking about practicality for non-software engineers which is probably 99.9% of the population. It might be fine for sorting and no one gives a shit about endianess. Common person would argue - why do they need to know the year first? Most people encounter dates in the same year, they already know we're in 2021 and it is not as important. Having to laboriously parse YYYY before getting to the most important bits, either month or day depending on what they're trying to do; doesn't seem too practical. I hate writing ISO 8601 dates, even though I know it is logical. Not everything logical works with humans. In my day to day life (not engineering use), I personally prefer inches and feet, they are just human scale dimensions. Conversion happens less often than you think - most people convey to others that this box is 12x8x8 inches. Conversion from inches to feet happens way less often. I hate fractions though. It would be great if a centimeter was twice as long in physical dimensions. It's just too granular and falls in an uncanny valley. And no one uses decimeter (10 cm) for some reason which is actually nice since it is roughly the size of the index finger.
- wahern 6y ago
  30 years ago when most literature was either published recently (newspapers, magazines, etc), or the date of publication was mostly irrelevant (books), your argument makes sense. If you cared at all, what mattered was usually the month and day. For most of the literature people read in the 21st century, especially this past decade, the year is the most important part. People normally couldn't care less whether something was published 3 days ago or 3 months ago. But knowing whether it was published 3 years ago makes all the difference in the world to its relevancy.
  - systemvoltage 6y ago
    I think I need to labor on my point a bit more. There are many use cases for dates. From publication date to planning vacation on a calendar. What is the most common use for a date? Calendar, I guess? The most frequently used dates we encounter are within +/- weeks from now. In a day to day use, YYYY is useless.
    - 6y ago
m_eiman 6y ago
While on the subject of time, could you Americans pretty please stop believing that the week starts on Sunday? It's just as wrong as your date format.
- yokaze 6y ago
  China and Japan have Sunday as the first day since the 4th and 8th century respectively: http://chartsbin.com/view/41671 http://chartsbin.com/view/41671. So presumably, you come from a Europe-centric view: http://chartsbin.com/view/41671 http://chartsbin.com/view/41671
  - FooBarWidget 6y ago
    China does? I'm Chinese and I'm pretty sure Chinese consider Monday to be the start.
    - yokaze 6y ago
      Ah, sorry. Then I am misinformed. The locale "zh_CN" does give me Sunday as the first, which seems then misaligned with actual practice.
    - Turing_Machine 6y ago
      Not according to: https://unicode-org.github.io/cldr-staging/charts/38/supplemental/territory_information.html https://unicode-org.github.io/cldr-staging/charts/38/supplem... Note that common usage and the official definition may well differ. Most Americans probably consider Monday the "first day of the week" as it is the first day in a standard work week. But officially, Sunday is the first day of the week.
      - rswail 6y ago
        Which is weird, because "god rested on the seventh day" and the Christian religion believes that to be Sunday, so it is the last day of the week. Why does the US think that the week starts on Sunday?
stochastimus 6y ago
The unmentioned benefits: it is fixed-width and follows most to least significant parts left-to-right. What this means is that the significance of the parts follows the same L-R convention as numbers, making it intuitively obvious which is the month and which is the day. Oh, and a simple string sort will sort timestamps correctly - very handy at the command line. Even db columns holding timestamps as strings will get the ordering right by default.
- mdeck_ 6y ago
  Both of these points are mentioned in the article.
tom-jh 6y ago
I use the 2021-02-26 format for every place that asks for a date without a clear format. All legal contracts, forms, email etc, across US and Europe. Never got any trouble for it - it seems people readily understand the format even if they may think it's a bit unusual. I wish it was the norm.
- aib 6y ago
  This has been my experience as well. Sometimes I tell onlookers that it's an ISO standard.
- SecurityLagoon 6y ago
  Yeah, I deal with so many different countries that it is a minefield using any other date format than RFC3339/ISO8601. I have been stung by having my birthday month and day inverted a few times when using DD/MM/YYYY format.
kinard 6y ago
I agree with this statement. We've started using it in our API calls.
LordHeini 6y ago
I would absolutely not use this for IT purposes if I could avoid it. The simple reason is that I have been bitten by time zone shenanigans way too often. The same stands for databases always use timestamptz and not just timestamp. Every frontend framework has functionality to properly and reliably format dates for a given locale. As for filenames. It contains a space which is a pita for command line use.
- rob74 6y ago
  This article is primarily about the date format, and that doesn't have anything to do with the timezone, so it's a bit unfair to hold time zone issues against it. Some issues are also self-made because people (including people who write libraries, frameworks etc.) choose to store a date (e.g. somebody's birthday) as a datetime...
- Grayskull 6y ago
  Date and time are separated by "T" and timezone is specifiable but optional. From wikipedia: "If a time zone designator is required, it follows the combined date and time. For example, "2007-04-05T14:30Z" or "2007-04-05T12:30−02:00"."
- trinix912 6y ago
  > As for filenames. It contains a space which is a pita for command line use. The biggest problem I see is the time notation part using colons. Windows still doesn't allow using them in filenames in most places.
globular-toast 6y ago
The US format is indeed awful but so is the European one really. ISO-8601 is the only one that makes sense, although the concept of months isn't really useful at all. But it's not always unambiguous. ISO-8601 supports local time. It's only an unambiguous timestamp of the time zone is included.
- young_unixer 6y ago
  > although the concept of months isn't really useful at all. Made me chuckle, but I agree.
- trinix912 6y ago
  > The US format is indeed awful but so is the European one really There are many different European formats, some countries even use (a slightly modified version of) ISO-8601, ex. in the Nordics.
lurkmurk 6y ago
"I can't remember the date to fill out this form. Can you help me, but give me the least informative part first?"
gorgoiler 6y ago
At best this is incomplete. Most humans talk about (month, date) tuples. US dates are big endian and written mm/dd. 12/25, 10/1, 2/28. They are elegant and compact and visually sort in the correct way eleven times out of twelve (11/12.) Short UK dates are spoken as “Jan 9th” “8th of March” and written as such, or sometimes “Feb 9”. I find them very less pleasing. Longer UK dates in Guardian format are prettier: 3 Jan 2022. US dates inevitably have to be unambiguous about years. This is indeed unwieldy because a slashed triple — 3/4/22 — is used in the UK too. (The slashed pair is uncommon so it’s clear that 3/4 is an American date.) Anything technical should indeed use ISO, but if you have an audience in a single locale it’s important to know your audience and localize (localise) accordingly.
- fredzel 6y ago
  I'd guess most people, at least in Europe, learn British English, so US format of MM/DD is not really intuitive.
bambax 6y ago
I got into the habit of writing dates in this way perhaps 20 years ago, in all my writings. People are sometimes surprised at first but the beauty of this is that they immediately get it. It's self-explanatory, obvious, in a way that no other format is.
FooBarWidget 6y ago
Coming from China, western date and time formats puzzle me. In China we use the ISO 8601 order for dates. Because of this, and also for all the reasons stated in the article, I use the ISO 8601 format in all my software. As a user, it really bugs me when an app uses either the European or the US format, but doesn't tell me which one it is.
- nayuki 6y ago
  China's date format isn't as good as ISO 8601. Let's ignore the 3 Chinese characters (年月日) for a moment. The problem is that the Chinese format does not use leading zero padding - e.g. 2021年5月8日 - which makes the format variable-length and much harder to sort.
deleted 6y ago
[deleted]
em500 6y ago
Free versions of the actual specs: https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i... https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_iso_wd_8601-2_2016-02-16.pdf https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_i... Or https://www.iso.org/obp/ui/#iso:std:iso:8601:-1:ed-1:v1:en https://www.iso.org/obp/ui/#iso:std:iso:8601:-1:ed-1:v1:en The ISO8601 yyyy-mm-dd format is fine and intuitive. What trips people up all the time is the ISO8601 yyyy-www-d format (year-week-weekday)[1]. People who know it well can appreciate the benefits. But it's deeply unintuitive to people who encounter it for the first time, that the year in yyyy-www-d sometimes differes from the year in the yyyy-mm-dd format. And a perpetual source of bugs when inexperienced devs use the wrong year specifier (https://news.ycombinator.com/item?id=18762988 https://news.ycombinator.com/item?id=18762988). The biggest wart in the spec IMO is the (optional) T in 2021-02-26T09:24, which makes the datetime format much harder to read for humans. [1] https://en.wikipedia.org/wiki/ISO_week_date https://en.wikipedia.org/wiki/ISO_week_date
- AlanYx 6y ago
  The "week date" format (yyyy-www-d) in ISO8601 is IMHO why it's usually better to refer to RFC3339, which doesn't allow the week date format. So many people are unaware that the ISO8601 format allows "week date" and/or don't understand its quirks, and articles like this one, which don't even mention that ISO8601 dates can appear in this format, compound the problem.
  - rswail 6y ago
    What about the Durations and Intervals? The "Week" format is great for planning purposes, because it allows a granularity between days and months with another whole number per year. Saying that a task will begin 2021-W08 and then defining the start of the week (ISO8601 says its a Monday), tells you exactly when it will start. Saying the task is 2021-W08/P4D tells you exactly when it starts and how long it will take. Or P4D/2021-02-25 says the same thing but in terms of when it will end. They're just as unambigious and just as useful.
lovelyviking 6y ago
I invented for myself this one: 2021-02-26_08-30-00_ And never looked back. Because since then I have no problems with dates anymore. If there is a need for 'ms' you can add them in the end or add more sections for more precision. For me it solves it.
- lazyasciiart 6y ago
  One day you'll need to read a date written by someone else.
  - lovelyviking 6y ago
    Or perhaps one day you'll need to read this one :) If I meet another date format I convert it to this one when possible. For instance I setup this date format for MacOS in Settings->Language & Region->Advanced->Dates: this way: Short: y-MM-dd Medium: y-MM-dd Long: y-MM-dd_HH-mm-ss Full: EEEE,y-MM-dd_HH-mm-ss You just put those strings there and it should work. In terminal you can do it too: date "+%Y-%m-%d_%H-%M-%S_" or datetime=$(date "+%Y-%m-%d_%H-%M-%S_")
valenterry 6y ago
ISO 8601 contains durations and time intervals which are totally undervalued! (https://en.wikipedia.org/wiki/ISO_8601#Time_intervals https://en.wikipedia.org/wiki/ISO_8601#Time_intervals) E.g.: 2021-05-01T12:00:00Z/P2H They are so convenient. Ever stored a tuple of two datetimes to model a time interval? E.g. a meeting that takes place on 2021-05-01T12:00:00Z and takes two hours? Don't! Instead, store it as an interval: "2021-05-01T12:00:00Z/P2H" Or are you creating an API where a duration or a time interval is expected? E.g. "give me all sales in this time period..." Using time intervals for that makes it so much more easy for people to code against it and execute manual queries. For JVM developers, there is a library out there that has amazing support: https://github.com/MenoData/Time4J https://github.com/MenoData/Time4J For python developers, there is pendulum which supports most of the functionality.
- em500 6y ago
  I agree it's undervalued. Sadly too few people are aware that a standard notation for time intervals even exists, and external software support is very sparse (e.g. lacking in Pandas, R, most SQL implementations). Which leads to too many devs rolling their own buggy solutions for datetime arithmetic.
- twic 6y ago
  As of Java 8, the JDK also has support for ISO duration formats, via java.time.Period and java.time.Duration.
- valbaca 6y ago
  100% agree that it's undervalued. Was just in a software design meeting where they were trying to figure out how to represent exactly this: a time interval. I had to repeat "Just read ISO 8601 and use it" like a dozen times. "Bu-bu-but what if we want to represent a recurring..." READ IT. AND USE IT.
- brewmarche 6y ago
  Shouldn't it be /PT2H instead of /P2H?
young_unixer 6y ago
Tangentially related: I hate GNOME's approach at configuring formats. In their format settings, you have to pick a country and that determines the format of dates, time, numbers, and the unit system. Of all the countries, none of them has the sane choice for all of the fields, namely: ISO 8601 for dates and times with 24h (no AM/PM), metric system (or SI, whatever), and dot as decimal separator. You can have sane dates, but then you have AM/PM in the clock. You can have 24h clock, but then you have a comma as decimal separator, etc. Can we add a country "Saneland" with the sensible options for all fields? cause that's where I want to be from. Saneland: the imaginary place where we use reasonable standards and things work.
- sebmellen 6y ago
  This is one of my biggest gripes with GNOME, along with the incredibly stupid lack of thumbnails in the file browser.
  - superzamp 6y ago
    And the way if forces you into a full-blown file search when you start typing letters and are just looking for files with that prefix...
    - hda2 6y ago
      I open a new terminal and tab my way to the file I want because it's quicker and less mentally-demanding than solving Gnome's UI puzzles. At least I used to until I had enough and switched to a different file manager.
  - matheusmoreira 6y ago
    That still hasn't been fixed? It's been so long it's become an old meme at this point. People still mock Linux for it...
- akvadrako 6y ago
  Probably those are from the locales package? en-dk is the best one, it is Europe standard english which I think fits all your requirements for Saneland.
kstenerud 6y ago
ISO-8601 was a good early attempt, but unfortunately it has some negative points: - Only offset-based time zones are allowed (which are next to useless). - Omitting the time zone defaults to local time, which renders the time ambiguous. Defaulting to UTC makes much more sense. - BC dates are all offset by 1 ("-1" = 2 BC). I know the reasons for this, but this could have been moved to the implementation and not exposed to the user. - Lots of silly things like fractional-minutes and multiple ways to represent the same data bloat the spec and implementations. This is why I rejected iso-8601 and developed my own for https://github.com/kstenerud/concise-encoding/blob/master/cte-specification.md#temporal-types https://github.com/kstenerud/concise-encoding/blob/master/ct... Examples: 2019-8-5 : August 5, 2019 -300-12-21 : December 21, 300 BC (proleptic Gregorian) 12:05:50.102 : 12:05:50 and 102 milliseconds UTC 4:00:00/Asia/Tokyo : 4:00:00 Tokyo time 2019-01-23/14:08:51.941245 : January 23, 2019, at 14:08:51 and 941245 microseconds, UTC 1985-10-26/01:20:01.105/America/Los_Angeles : October 26, 1985, at 1:20:01 and 105 milliseconds, Los Angeles time 25192-11-01/03:00:00/48.86/2.36 : November 1st, 25192, at 3:00:00, at whatever is in the place of Paris at that time (global coordinates 48.86, 2.36)
jbj 6y ago
my birthday is at the end of the month, during a processing of a document for my US visa 10+ years ago, I was dealing with 2 different sites, one accomodating my local date formatting, and one fixed for the US standard. I was puzzled that I had been made 2 years younger when verifying my data, turned out my birth date of month was now month number 24+ of the year, pushing my birth ahead, and my birtb month had become my birth date of month.
_raz 6y ago
I like how the first paragraph ends with "I’m here to (hopefully) change your mind by introducing you to a lesser-known date format called ISO 8601." It seems so foreign to me, and most people i know, to use anything but ISO8601 or RFC3339. Might be, as with most things, that we here up in the Nordics simply are used to it.
antihero 6y ago
It is a good format for sorting, but misses the point of use. As humans, we want to read the most significant data to our use case first. The author confuses value to the reader with magnitute. In normal numbers, they happen to be the same thing. In most cases, we want to discern between days first, them months, then years. If you look at a list of dates: 2021-01-01 2021-01-02 2021-01-03 2021-01-04 You're just going to be seeing a heap of noise before you see the actual number you care about. If you consider that days are the most valuable, then months, then years, you get the UK/European format. 01/01/2021 02/01/2021 03/01/2021 04/01/2021
- TeMPOraL 6y ago
  > In most cases, we want to discern between days first, them months, then years. That really, really depends on particulars on your life. While I strongly dislike the US format of putting the month first, the irony is, the month is the most important datum for most of the dates I read with. Year is usually obvious given particular context (it's typically either the current one, the next one, or sometimes the previous one). Days don't matter for anything that isn't in the same month. I'd go as far as saying that months are typically the most important for most people in XXI century, then days, then years. But that's no problem for punctuated date formats in general. People don't read things linearly at letter level, they deconstruct tokens in a random-access way. Separators like - or / help clearly identify which part is which (compare how easy it is to read 03/01/2021 with 03012021), and there's no extra cost associated with reading off the part in the middle. The benefits of YYYY-MM-DD notation on top of the above are: - With all terms being fully expanded, dates line up vertically as well, which helps when dealing with stacks of documents or tabular data. - Being ordered by magnitude like normal numbers provides a Schelling point for interpretation[0]. That is, when a random person who wasn't exposed to much computing or internationalization before sees 2021-01-03, they will automatically assume that 01 must be the month, because writing YYYY-DD-MM would be dumb and inconsistent with how numbers are written in general. Yes, both of these apply to DD/MM/YYYY, but, YYYY-MM-DD also gets you sane lexicographic sorting, which the UK/European format doesn't. It's super useful feature not just when dealing with computers, but also when perusing any kind of date index. ISO 8601 dates work much like words in a dictionary, you can binary-search through them. -- [0] - https://en.wikipedia.org/wiki/Focal_point_(game_theory) https://en.wikipedia.org/wiki/Focal_point_(game_theory)
roelschroeven 6y ago
I wish HTTP would ISO 8601 for its dates, or anything sane in any case. Dates in HTTP headers are meant to be machine-readable, right? Then why use month names instead of numbers? Why include the day name? "Wed, 21 Oct 2015 07:28:00 GMT" is just silly. And that's just the preferred format; there are two other formats that are just as idiotic that recipients are supposed to understand. https://tools.ietf.org/html/rfc7231#section-7.1.1.1 https://tools.ietf.org/html/rfc7231#section-7.1.1.1
BoppreH 6y ago
I have a question for the timezone crowd: why does the ISO 8601 format include a UTC offset like "+09:00" instead of a more useful region name like "Asia/Tokyo"[0]? Take for example the timestamp "2025-07-20 13:30:00+09:00": - If it was supposed to represent a meeting in Asia/Tokyo and that region changes offsets (DST or political reasons), we don't have enough information to update the timestamp because it could also have been Asia/Seoul or other. - If a leap second is subtracted at 2025-07-20 13:30:01+09:00, we'll see that timestamp twice and it's now ambiguous which moment it refers to. - If a leap second is added at 2025-07-20 13:29:59.9+09:00, we'll never see that timestamp and now it's not a valid moment anymore. - Because of the regional offset changes and leap seconds between now and then, I can't reliably subtract that date from any other date to calculate durations. I'm struggling to think of a situation where this timestamp format is the correct one. Why don't we have "2025-07-20 13:30:00+09:00[Asia/Tokyo]" or even just "2025-07-20 13:30:00 [Asia/Tokyo]"? [0]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
- sirn 6y ago
  I think because it would defeat the portability of a timestamp because Asia/Tokyo isn't constant and you cannot lookup the offset without relying on external database that takes in ("2021-02-26 18:38:00", "Asia/Tokyo") as a parameter. Offset in zoneinfo changes depending on day of a year, and sometimes even hour of a day, and the database of timezone is constantly updated (latest zoneinfo is version 2021a). So while having 2021-02-26 18:38:00 Asia/Tokyo as a timestamp would more accurately represent the time, it would create another set of issues, namely requiring a database to look it up, and requiring to keep those database in sync in all systems in the world. Having both may be redundant because in that case you can't still trust the offset. There are alternative systems such as TAI64[1] based on TAI[2] that are meant to accurately represent the moment in time without being subjected to leap second (only account them on conversion to UTC). The main issue is TAI64 is not really human readable (e.g. @4000000037c219bf2ef02e94) and would still require database of leap seconds to accurately convert back to UTC. [1]: http://cr.yp.to/libtai/tai64.html http://cr.yp.to/libtai/tai64.html [2]: https://en.m.wikipedia.org/wiki/International_Atomic_Time https://en.m.wikipedia.org/wiki/International_Atomic_Time
deleted 6y ago
[deleted]
simon04 6y ago
Has anyone succeeded in configuring GNU/Linux to consistently output dates in ISO 8601 format? A partial solution involves... ls -l --time-style=full-iso git log --date=iso date --iso-8601=s # or date --rfc-3339=s export TIME_STYLE='long-iso'
fmajid 6y ago
Except `YYYY-MM-DD HH:MM:SS` is not the ISO 8601 date format, `YYYY-MM-DDTHH:MM:SS` is (note the T). Replacing the T with a space is a RFC3339 extension.
alkonaut 6y ago
I wouldn’t call ddmmyy “European”. Many countries use yymmdd (nordics, for example) which is the iso order. And the order in which alphabetical or numerical sorting works out of the box. Other than inertia/tradition there is really no excuse for shuffling around a date in any other way.
- hanche 6y ago
  In Norway, the current standard is dd.mm.yy. Before computers, it was d/m-yy (no leading zeroes). I come across yyyy-mm-dd once in a while, but it is sort of rare.
wankeler 6y ago
26 II 2021 Job done
joshspankit 6y ago
In my opinion, YYYY-MM-DD is the last unambiguous date format left. I hold the line, and I will die on this hill.
m463 6y ago
I was going to say this is a lot more readable than that other date/time format: 2021-02-26T12:25:04Z or 2020-01-30T03:14:15+05:00 but turns out its the same one
brnrr 6y ago
Here's an interesting date format most of HN probably haven't heard of; military date-time-groups[1]. 270009LFEB21 Translation: The 27th, 00:09, "L" timezone (+11, NATO timezone[2]), February, 2021. Advantages: - it's much more compact than ISO8601. - the most significant information is first; the date. - the second-most significant information is second; the time. - the timezone is a single alphanumeric character. - when military paperwork has a box at the top that says "DTG", everyone knows the format. - I'm pretty sure it's a standard across all NATO militaries. [1] https://en.wikipedia.org/wiki/Date-time_group#Military_Date_Time_Group https://en.wikipedia.org/wiki/Date-time_group#Military_Date_... [2] https://en.wikipedia.org/wiki/List_of_military_time_zones https://en.wikipedia.org/wiki/List_of_military_time_zones
- nayuki 6y ago
  I never heard of this before. It looks like an awful brain teaser, like an extension of the American middle-endian format to the extreme. ISO 8601: [YYYY][MM][DD][hh][mm][tz] (0 1 2 3 4 TZ) Military DTG: [DD][hh][mm][tz][MM][YY] (2 3 4 TZ 1 0)
mdip 6y ago
Date/Time is frequent topic[0] for me. Generally speaking, a lot of these issues are knowing when it's appropriate to use what format. When displaying a date to a user, you do it in their configured local time, and in their configured date/time format. I don't think the author is advocating changing that behavior[1]. Where the problem comes in is "how you store date/time values". Normally, I don't find myself arguing as to the format. Generally speaking, people default to ISO-8601 for log file naming (many probably not realizing that's what they're doing -- aiming only for a naturally sortable list). The places I tend to store dates (databases) define how they're stored, otherwise. That doesn't mean a developer isn't going to store the date in server local/user local time (and often make discovering the reference time zone impossible). Please don't do this. Store in UTC. I'm not sure why the author is so hung up about the ordering of the dates, but while I worked in telecom, I briefly had a boss that was really particular about that (I've worked for a few folks in the UK, only this first boss had hang-ups). The US ordering probably originates from the most common way dates are spoken in the US: "Januaray 17th". A year is less frequently necessary, but when it is, it's tacked on the end. I don't think anyone thinks the way we write dates is particular superior, it's just the way we've done it since we first learned about dates. One thing I learned when I started working regularly with non-US folks. Never use numerical dates. Even if you write it in the format they are comfortable with, if there's any ambiguity, they're likely to assume you wrote it in the US format. I started writing/abbreviating month names. I ended up altering the written order, as well "17th of January or 17 Jan" because that particular first boss jokingly-non-joked about how obnoxious the other way was. Everybody's got their tabs/spaces war, I guess! [0] OK, so it's more of a pet peeve. [1] While it would be nice if we all used the same date/time format in our day-to-day life, it's one of those things that I'll wager will never happen... and I'd argue that doing so would cause more problems than it would help.
lowbloodsugar 6y ago
What about the Y10k bugs?
jeff-davis 6y ago
Years before 0 or after 9999 are not defined in 8601 (there is some attempt to allow for them, but it's not really specified). Also, the lexicographic sorting would be ruined (if it isn't already by timezones).
gnulinux 6y ago
I prepend my filenames with soemthing like `YYYY-MM-DD_HH:MM:SS.sss` or if second is enough `YYYY-MM-DD_HH:MM:SS`. The `T` there makes it hard to read for humans imho.
scottmcdot 6y ago
I've been caught out by doing date comparisons in Spark SQL using string yyyy-mm-dd against string yyyy-mm-dd 00:00:00. It's easy to think that the trailing 00:00:00 will have no impact on date comparisons but it does! Lesson learnt: use substr(date, 1,10)
aimor 6y ago
My biggest complaint is that Windows doesn't allow ":" in file names. I just substitute "-", which is good enough, but not standard.
smiley1437 6y ago
Great format, but once 2032 rolls around everyone will go back to a 2 digit shorthand for the year. Because humans are lazy.
deleted 6y ago
[deleted]
therealmarv 6y ago
Even the xkcd https://xkcd.com/1179/ https://xkcd.com/1179/ does not mention or gets wrong that yyyymmdd is also right and allowed in ISO 8601. Especially useful when you add time. You don't e.g. want character ":" in your file name 20210226T205418 (local time here)
davidbanham 6y ago
A note from the front line. I actually use 8601 dates in a date-heavy consumer product ( https://clubman.app https://clubman.app ) and it’s hands down the feature I most consistently get user feedback on. It’s always “Why are the dates all American format? Can you change them to English?” And then I try to patiently explain that they’re actually international format. People seem to have internalised that any date format they find slightly unfamiliar is “the bad American one” I’m in the process of cutting everything I can over to “24th Jan 2020” style.
- jamie_ca 6y ago
  Another advantage to outputting 8601 dates is it's easy to mechanically parse - you can probably find some JS to rewrite the 8601 dates coming from the server into whatever the user's current locale is. Bonus points: if your timestamps are UTC, the frontend reformatting can even take timezones into account (such that an American and an Australian could correctly see different dates for the same timestamp).
  - davidbanham 6y ago
    I did try rewriting dates into a user's locale as specified by the browser. The trouble there is that a lot of people seem to have that set to en-US rather than en-AU. So I still got a bunch of people unhappy that the dates were American!
CivBase 6y ago
> If you’re smart enough, you’ve probably also noticed that the American one makes no sense and is just awful That's simply not true. The American format is designed to reflect how we normally pronounce dates or write them out in long form (eg "September 11th, 2001"). The European format is also flawed. It's similarly divided into three tokens (day, month, year) but they are ordered so that the tokens represent greater magnitudes of time moving from left to right, big-endian-style. The problem is each token is a decimal number which is traditionally written in little-endian-style. So like the American format, you still need special understanding of the format to read dates and they cannot be trivially sorted. The ISO 8601 format is little-endian all the way through so it is trivially sorted. UNIX time is even easier to sort and compresses much better, but it's rather difficult for humans to read.
- heurisko 6y ago
  > The American format is designed to reflect how we normally pronounce dates or write them out in long form (eg "September 11th, 2001"). In the UK at least, we don't write or say dates in that order. With the exception of September 11th. I believe it's the same in German, 4te Juni etc.
itcrowd 6y ago
I have recently been inviting my American colleagues to meetings using times-as-American-dates format. In other words, proposing meetings to be on 02/26/21 at 25:23 (This example meaning February 26th 2021 at 25 minutes past 23 hours).
gr__or 6y ago
> a lesser-known date format called ISO 8601 is he being ironic? One of the things I love most about 8601 is it being supported by basically every* std lib (and definitely every library working with dates) * JS, Python, Ruby, PostgreSQL,...
Pinus 6y ago
Off topic, but I can't resist: Using Comic Neue with Comic Sans as fallback must be the typographic equivalent of russian roulette.
emergie 6y ago
Date formats are pure fun. ['en-US','en-IE','en-GB','en-ZA','de-DE','es-ES','nl-NL','pl-PL','ru-RU','cs-CZ','sv-SE','fi-FI','lv-LV'] .forEach(lang => console.log(lang + ': ' + new Date('2020-02-04').toLocaleDateString(lang, {day:'numeric', month:'numeric', year:'numeric'}))) en-US: 2/4/2020 en-IE: 4/2/2020 en-GB: 04/02/2020 en-ZA: 2020/02/04 de-DE: 4.2.2020 es-ES: 4/2/2020 nl-NL: 4-2-2020 pl-PL: 4.02.2020 ru-RU: 04.02.2020 cs-CZ: 4. 2. 2020 sv-SE: 2020-02-04 fi-FI: 4.2.2020 lv-LV: 2020.02.4.
justnotworthit 6y ago
> And the American format just makes no sense > Maybe the European date format is better because the elements are in the order of relevance? > ... when we’re talking about events occuring on a day-to-day basis, however I can think of numerous cases when the year and the month are more relevant I think that's the "sense" of the American one. It optimizes "metal sort" for month.
account42 6y ago
Having mm/dd/yyyy and dd.mm.yyyy wouln't even be so bad if people did not also write mm.dd.yyyy and dd/mm/yyyy and mm-dd-yyyy and dd-mm-yyyy and mm.dd.yy and dd/mm/yy and mm-dd-yy and dd-mm-yy and mm.dd and dd.mm and mm/dd and dd/mm. Of course even then, yyyy-mm-dd is best.

367 points by kirbykevinson 6y ago

kitd 6y ago

The real purpose of endianness which is missed here is the ability to sort. Sorting a list of iso8601 dates alphabetically means sorting them chronologically too.

deleted 6y ago
[deleted]
k_sze 6y ago
Until we hit year 10000, but yeah, that's still a looong time to go.
- est 6y ago
  There's some proposal that this year 2021 is actually 12021, to make the year neutral of some specific religious event.
  - ComputerGuru 6y ago
    I know you’re not saying you are encouraging it and it’s just a related but of trivia, but I find that hilarious. Because when someone asks “why start there?” the answer “it’s a thousand years before Jesus Christ was born, the millennium heralding his arrival” is better? (I’m not even Christian but I also don’t have a chip on my shoulder and can accept its influence on the world)
    - bhaak 6y ago
      It's ten thousand years before the assumed (but likely wrong) birthday of Jesus Christ, to have a positive date for all written human history (well, until we find the archives of Atlantis) and an easy round offset for the prevalent human calender in use.
    - grey_earthling 6y ago
      The answer is “because -10000 CE is an approximation of the beginning of human civilisation, using this epoch removes negative year numbers from all historical dates, and it's simple to convert from the ubiquitous CE epoch”. https://en.wikipedia.org/wiki/Holocene_calendar https://en.wikipedia.org/wiki/Holocene_calendar
  - mattashii 6y ago
    ... which is funny, because the gregorian calendar is supposedly based on a compromise between some years that christ was supposedly born in (the chosen year 1 is none of those, according to research, as he was born in 6-4 BC [0]). So now we have: another calendar, that has a starting year that is defined by subtracting an arbitrary number from a compromise between alledged years some person was born in. I love how humanity has the capability to invent new things with increasing complexity. [0] https://en.wikipedia.org/wiki/Anno_Domini#Birth_date_of_Jesus https://en.wikipedia.org/wiki/Anno_Domini#Birth_date_of_Jesu...
  - TeMPOraL 6y ago
    Yup. I have a calendar for 12021 hanging in my office, and I very like the sentiment it expresses. I tried to use the Holocene years with other people, but they remain unconvinced.
eesmith 6y ago
It's there: > This not only makes all of the dates look equally nice, but also, coupled with other quirks of this format, allows the files with the date in the name to be sorted just by the filename. My issue is with: > Simplified, the core date format looks like this: yyyy-mm-dd hh:mm:ss Here are the examples at https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601 2021-02-26T06:22:59+00:00 2021-02-26T06:22:59Z 20210226T062259Z Note the "T" instead of a space between the date and time? That's what the spec says: https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_tim... . "Separating date and time parts with other characters such as space is not allowed in ISO 8601, but allowed in its profile RFC 3339." Note the optional use of "-" and ":"? That's "basic" vs. "extended" formats. Plus the optional timezone specifier (if not present, assume it's the same timezone). There's also optional support for microseconds.
- kirbykevinson 6y ago
  I omitted this detail on purpose to not distract the reader who doesn't know much about date formats.
  - eesmith 6y ago
    How would you describe the accuracy and veracity of > "Here there’s only one correct way to write a date," given that there are multiple correct ways, and the way shown wasn't actually ISO 8601 but RFC 3339?
    - kirbykevinson 6y ago
      Yes, technically there are some edge cases where you can write things differently (apart from what you mentioned, one is, for example, writing the UTC time zone by Z vs +00:00 and another is adding additional precision to the date), but for the end user it's basically the same. Let's not ruin the illusion here :)
      - eesmith 6y ago
mjevans 6y ago
That's also the only time (full) European dates make sense, when writing them on the right hand side of a ledger page so that the exterior of the ledger / book is indexed with the largest components on the edge of the page. US dates only make sense if you don't care about the year and are writing on the left most side of a page; that might make sense if ink or paper is at a premium.
- orwin 6y ago
  My great great grandfather wrote a book about this 120 years ago! And yes, it was for taxes and accounting.
- nayuki 6y ago
  What you said about European dates (e.g. 27/02/2021 today) is not strictly true. The rightmost character is the ones digit of the year, and it is not the largest component. According to your rules, 01/01/2019 would be "larger" than 01/01/2021 because 9 is larger than 1. The blog post already made this observation, saying that YMD is the only format where the endianness of the date components match the endianness of the numbers; DMY does not have this property. If you wanted to sort dates correctly on the right hand side, you need to write the numbers backwards too, like "72/20/1202".

k_sze 6y ago

I teach my 9-yo daughter to write dates in ISO 8601 format whenever permissible, too. I tell her that all other formats that her school teaches her are just nonsense and wrong.

fouronnes3 6y ago
Is her middle name \";DROP TABLE users;?
deleted 6y ago
[deleted]
codeful 6y ago
this is responsible and good parenting! thumbs up
euroderf 6y ago
Raise her on hexadecimal too. She will thrive.
- k_sze 6y ago
  Now now, let’s not put the cart before the horse. Binary first, and then boolean logic, and then automata theory, and then...

jiggawatts 6y ago

The real advantage is that Azure and AWS and every other US-centric cloud service insists on showing me that something happened on the 3/11/2021. It's a wild guess to figure out if that is the 11th of March or the 3rd of November. Unless there's also another date with a number higher than 12 in it, there is no way to tell. None. None whatsoever. For US staff with US regional settings, it's always obvious which date is correct. That is the one single case where there is no confusion. This works as expected for just 4% of the world population, but it is those 4% of the world that get to decide the date format. It's the most obnoxiously American attitude imaginable to ignore this issue because it doesn't affect them... only the other 96% of the planet. /rant over

vbezhenar 6y ago
It took many decades to widely adopt UTF-8. I think that one of the reasons was that US companies did not really care about character encodings, as it's not something they have to often deal with. Even today managing multiple keyboard layouts is a pain in most operating systems, it's buggy, it does not have enough configuration options, it's not convenient. Probably because most US developers never tried to use that functionality.
- jacobolus 6y ago
  Mac Firefox and Mac Chrome both break a bunch of keyboard shortcuts if you use a non-US-ANSI keyboard. Safari handles alternate layouts correctly. Just yesterday I learned that on an ISO Spanish keyboard, both of those browsers will pop up a help menu for ⌘⇧7. The logic goes: ⇧7 means / on a Spanish ISO keyboard, and ⇧/ means ? on a US-ANSI keyboard, therefore ⌘⇧7 is by the transitive property of inter-layout shift functions equivalent to ⌘?, which is the shortcut for opening the help menu. They don't pop open the help menu if you press ⌘⇧', the actual ISO Spanish layout way to type ⌘?
  - misterS 6y ago
    Stuff like this is the reason why I, as a non-american software engineer, use `US_en` layouts on all my machines.

rchaves 6y ago

yyyy-mm-dd is so nice you can just work with strings for your date stuff, converting to objects and back is tedious Shameless plug: I built a python library to do exactly that https://pypi.org/project/yyyy-mm-dd/ https://pypi.org/project/yyyy-mm-dd/

grenoire 6y ago
Quite nifty and clean; I think this could play well with support for the duration (P-Y-M-D...) format in ISO 8601 that declares a positive offset. https://en.wikipedia.org/wiki/ISO_8601#Durations https://en.wikipedia.org/wiki/ISO_8601#Durations
- akavel 6y ago
  Interesting, didn't know about that! Do you know of some canonical way of expressing negative offsets in spirit of ISO 8601? I don't seem to see those mentioned in the article...
  - grenoire 6y ago
    Unfortunately not, for the project I'm working on right now I only needed 'forward' durations. There's a W3C extension that proposes a preceding - sign for negative durations, which I think it's fair https://www.w3.org/TR/xmlschema-2/#duration https://www.w3.org/TR/xmlschema-2/#duration. The ISO standard explicitly declares durations to be non-negative, on the other hand. As close to canonical as you can get.
  - rswail 6y ago
    You can specify an interval as start/duration, start/end, or duration/end. So you could specify a negative offset as a duration and the end time. P2H/2021-02-26T13:30Z is two hours prior or T11:30Z on the same date.
globular-toast 6y ago
It's not tedious if you do it right. All of your conversions should be done in your I/O layer and nowhere else. For many applications that means there's a single place to do it. Hardly tedious. I notice that your library is targeted at notebooks, though. It seems useful in that context, but not for general programming.

hannob 6y ago

There's another aspect you may not know about: It's close to how it's done in chinese, which is 2021年3月17日. They use different separators (the chinese words for year, month and day), but it's close enough. Given that china is the country with the largest population it may not be a bad idea to use something a large number of people will easily understand.

CyberRabbi 6y ago
Maybe we should also start speaking Chinese since it may not be a bad idea to use something a large number of people will easily understand. Edit: this is not sarcasm. It’s simple logic, unless there is something wrong with learning other languages.
- monsieurbanana 6y ago
  Sigh... I never remember the names of the logical fallacies, I have to look up them, thanks a lot. Anyways, here's yours: Slippery Slope.
  - CyberRabbi 6y ago
    Where’s the logical fallacy? More people natively speak Chinese than any other language in the world. If you want to maximize the exposure of your ideas, it’s only logical to render them in Chinese. It’s the same reason I prefer to distribute applications over the web. FYI: English has ~1100 million total speakers but only 318 millon native speakers, while Chinese has 918 million native speakers. https://www.visualcapitalist.com/100-most-spoken-languages/ https://www.visualcapitalist.com/100-most-spoken-languages/
    - dataflow 6y ago
      https://www.statista.com/statistics/266808/the-most-spoken-languages-worldwide/ https://www.statista.com/statistics/266808/the-most-spoken-l... Unless it's already out of date...
    - 6y ago

atoav 6y ago

As a european I use ISO 8601 for everything since about 5 years. One point is also: if you manually write a date, the easiest to remember part (the year) comes first, then the month (which is usually also easily remembered) and then the thing that you can forget at times. This feels better than the other way around.

JdeBP 6y ago
I can beat that slightly. I have things with ISO 8601 dates written on them, by me, dating from 1986. Yes, I started using it before it was formally published as a standard. I initially used the basic format.

tpetry 6y ago

The article is missing one of the best features of iso 8601: it‘s string form is naturally sortable. You don‘t need any specific logic for sorting, so e.g. your filesystem will automatically sort files correctly if you prefix them with a iso 8601 date.

Someone 6y ago
FTA: “The elements are always padded to the maximum number of digits. This not only makes all of the dates look equally nice, but also, coupled with other quirks of this format, allows the files with the date in the name to be sorted just by the filename.”
m12k 6y ago
Which is a side effect of being consistent with the way we write all other numbers, with the value represented by each digit declining as we go left to right.
- jeff-davis 6y ago
  Lexicographic sorting does not work for numbers of different lengths, e.g. "100" and "9".
  - pwg 6y ago
    It does if you zero fill the shorter number to an equal number of digits: "100", "009".
    - koolba 6y ago
      There's a special place in hell for people that using variable length representations for time units that are meant to be consumed by machines. I think it's across the hall from the room for people who configure servers for anything besides UTC.
      - JdeBP 6y ago

wodenokoto 6y ago

People look at ISO-8601 and think year-month-day looks great! But don’t realize that it also includes thing like —month-day (yes, you don’t need to include year to have a valid iso date!) year-week, year-day and lots of other things. So I would generally advise against accepting iso formatted dates and instead decree a single date format. https://en.m.wikipedia.org/wiki/ISO_8601 https://en.m.wikipedia.org/wiki/ISO_8601

tuukkah 6y ago
> The 2000 version allowed writing "--04-05" to mean "April 5"[23] but the 2004 version does not allow omitting the year when a month is present.

makach 6y ago

It's time to come clean, I love you ISO8601 and I always have. You complete me.

rollulus 6y ago

At the risk of nitpicking, I prefer RFC 3339, which is a profile of ISO 8601. ISO 8601 provides room for things you typically don't want, e.g. dropping time zone offsets. While I'm typing this I realise that I've never actually read the ISO 8601 spec, like probably most people here, because it's not free. I cannot even be sure it really exists.

SideburnsOfDoom 6y ago
> I've never actually read the ISO 8601 spec, like probably most people here Indeed. The comprehensive Wikipedia article on ISO8601 is as far as we go https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601 Thanks for pointing out rfc3339 - this appears to be the "useful part" of ISO8601 for data interchange. https://tools.ietf.org/html/rfc3339 https://tools.ietf.org/html/rfc3339
- wongarsu 6y ago
  Draft versions of the ISO standard are easy enough to find on the internet. But the Wikipedia article is excellent and covers just about everything.
  - diggernet 6y ago
    Yes, and I've read the drafts of ISO 8601-1:2019 and 8601-2:2019. But can I rely on them? They were published in 2016. What has changed between then and the official release in 2019? Also, neither RFC3339 nor Wikipedia discuss features like open-ended time intervals. They are in the draft, but did they make the final cut? And in what form? No idea... The closest I've found to "official" documentation of the 2019 update is a short summary of the changes, hosted by Library of Congress[1]. Which is nice to have, but I sure wish the real standard was public. [1]https://www.loc.gov/standards/datetime/ https://www.loc.gov/standards/datetime/
CuriousNinja 6y ago
> never actually read the ISO 8601 spec ... because it's not free I was very surprised to discover this. Why are they charging money for the specification of a date format? I would expect standards like these to be published in public domain.

systemvoltage 6y ago

No one here is talking about practicality for non-software engineers which is probably 99.9% of the population. It might be fine for sorting and no one gives a shit about endianess. Common person would argue - why do they need to know the year first? Most people encounter dates in the same year, they already know we're in 2021 and it is not as important. Having to laboriously parse YYYY before getting to the most important bits, either month or day depending on what they're trying to do; doesn't seem too practical. I hate writing ISO 8601 dates, even though I know it is logical. Not everything logical works with humans. In my day to day life (not engineering use), I personally prefer inches and feet, they are just human scale dimensions. Conversion happens less often than you think - most people convey to others that this box is 12x8x8 inches. Conversion from inches to feet happens way less often. I hate fractions though. It would be great if a centimeter was twice as long in physical dimensions. It's just too granular and falls in an uncanny valley. And no one uses decimeter (10 cm) for some reason which is actually nice since it is roughly the size of the index finger.

wahern 6y ago
30 years ago when most literature was either published recently (newspapers, magazines, etc), or the date of publication was mostly irrelevant (books), your argument makes sense. If you cared at all, what mattered was usually the month and day. For most of the literature people read in the 21st century, especially this past decade, the year is the most important part. People normally couldn't care less whether something was published 3 days ago or 3 months ago. But knowing whether it was published 3 years ago makes all the difference in the world to its relevancy.
- systemvoltage 6y ago
  I think I need to labor on my point a bit more. There are many use cases for dates. From publication date to planning vacation on a calendar. What is the most common use for a date? Calendar, I guess? The most frequently used dates we encounter are within +/- weeks from now. In a day to day use, YYYY is useless.
  - 6y ago

m_eiman 6y ago

While on the subject of time, could you Americans pretty please stop believing that the week starts on Sunday? It's just as wrong as your date format.

yokaze 6y ago
China and Japan have Sunday as the first day since the 4th and 8th century respectively: http://chartsbin.com/view/41671 http://chartsbin.com/view/41671. So presumably, you come from a Europe-centric view: http://chartsbin.com/view/41671 http://chartsbin.com/view/41671
- FooBarWidget 6y ago
  China does? I'm Chinese and I'm pretty sure Chinese consider Monday to be the start.
  - yokaze 6y ago
    Ah, sorry. Then I am misinformed. The locale "zh_CN" does give me Sunday as the first, which seems then misaligned with actual practice.
  - Turing_Machine 6y ago
    Not according to: https://unicode-org.github.io/cldr-staging/charts/38/supplemental/territory_information.html https://unicode-org.github.io/cldr-staging/charts/38/supplem... Note that common usage and the official definition may well differ. Most Americans probably consider Monday the "first day of the week" as it is the first day in a standard work week. But officially, Sunday is the first day of the week.
    - rswail 6y ago
      Which is weird, because "god rested on the seventh day" and the Christian religion believes that to be Sunday, so it is the last day of the week. Why does the US think that the week starts on Sunday?

stochastimus 6y ago

The unmentioned benefits: it is fixed-width and follows most to least significant parts left-to-right. What this means is that the significance of the parts follows the same L-R convention as numbers, making it intuitively obvious which is the month and which is the day. Oh, and a simple string sort will sort timestamps correctly - very handy at the command line. Even db columns holding timestamps as strings will get the ordering right by default.

mdeck_ 6y ago
Both of these points are mentioned in the article.

tom-jh 6y ago

I use the 2021-02-26 format for every place that asks for a date without a clear format. All legal contracts, forms, email etc, across US and Europe. Never got any trouble for it - it seems people readily understand the format even if they may think it's a bit unusual. I wish it was the norm.

aib 6y ago
This has been my experience as well. Sometimes I tell onlookers that it's an ISO standard.
SecurityLagoon 6y ago
Yeah, I deal with so many different countries that it is a minefield using any other date format than RFC3339/ISO8601. I have been stung by having my birthday month and day inverted a few times when using DD/MM/YYYY format.

kinard 6y ago

I agree with this statement. We've started using it in our API calls.

LordHeini 6y ago

I would absolutely not use this for IT purposes if I could avoid it. The simple reason is that I have been bitten by time zone shenanigans way too often. The same stands for databases always use timestamptz and not just timestamp. Every frontend framework has functionality to properly and reliably format dates for a given locale. As for filenames. It contains a space which is a pita for command line use.

rob74 6y ago
This article is primarily about the date format, and that doesn't have anything to do with the timezone, so it's a bit unfair to hold time zone issues against it. Some issues are also self-made because people (including people who write libraries, frameworks etc.) choose to store a date (e.g. somebody's birthday) as a datetime...
Grayskull 6y ago
Date and time are separated by "T" and timezone is specifiable but optional. From wikipedia: "If a time zone designator is required, it follows the combined date and time. For example, "2007-04-05T14:30Z" or "2007-04-05T12:30−02:00"."
trinix912 6y ago
> As for filenames. It contains a space which is a pita for command line use. The biggest problem I see is the time notation part using colons. Windows still doesn't allow using them in filenames in most places.

globular-toast 6y ago

The US format is indeed awful but so is the European one really. ISO-8601 is the only one that makes sense, although the concept of months isn't really useful at all. But it's not always unambiguous. ISO-8601 supports local time. It's only an unambiguous timestamp of the time zone is included.

young_unixer 6y ago
> although the concept of months isn't really useful at all. Made me chuckle, but I agree.
trinix912 6y ago
> The US format is indeed awful but so is the European one really There are many different European formats, some countries even use (a slightly modified version of) ISO-8601, ex. in the Nordics.

lurkmurk 6y ago

"I can't remember the date to fill out this form. Can you help me, but give me the least informative part first?"

gorgoiler 6y ago

At best this is incomplete. Most humans talk about (month, date) tuples. US dates are big endian and written mm/dd. 12/25, 10/1, 2/28. They are elegant and compact and visually sort in the correct way eleven times out of twelve (11/12.) Short UK dates are spoken as “Jan 9th” “8th of March” and written as such, or sometimes “Feb 9”. I find them very less pleasing. Longer UK dates in Guardian format are prettier: 3 Jan 2022. US dates inevitably have to be unambiguous about years. This is indeed unwieldy because a slashed triple — 3/4/22 — is used in the UK too. (The slashed pair is uncommon so it’s clear that 3/4 is an American date.) Anything technical should indeed use ISO, but if you have an audience in a single locale it’s important to know your audience and localize (localise) accordingly.

fredzel 6y ago
I'd guess most people, at least in Europe, learn British English, so US format of MM/DD is not really intuitive.

bambax 6y ago

I got into the habit of writing dates in this way perhaps 20 years ago, in all my writings. People are sometimes surprised at first but the beauty of this is that they immediately get it. It's self-explanatory, obvious, in a way that no other format is.

FooBarWidget 6y ago

Coming from China, western date and time formats puzzle me. In China we use the ISO 8601 order for dates. Because of this, and also for all the reasons stated in the article, I use the ISO 8601 format in all my software. As a user, it really bugs me when an app uses either the European or the US format, but doesn't tell me which one it is.

nayuki 6y ago
China's date format isn't as good as ISO 8601. Let's ignore the 3 Chinese characters (年月日) for a moment. The problem is that the Chinese format does not use leading zero padding - e.g. 2021年5月8日 - which makes the format variable-length and much harder to sort.

deleted 6y ago

[deleted]

em500 6y ago

Free versions of the actual specs: https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i... https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_iso_wd_8601-2_2016-02-16.pdf https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_i... Or https://www.iso.org/obp/ui/#iso:std:iso:8601:-1:ed-1:v1:en https://www.iso.org/obp/ui/#iso:std:iso:8601:-1:ed-1:v1:en The ISO8601 yyyy-mm-dd format is fine and intuitive. What trips people up all the time is the ISO8601 yyyy-www-d format (year-week-weekday)[1]. People who know it well can appreciate the benefits. But it's deeply unintuitive to people who encounter it for the first time, that the year in yyyy-www-d sometimes differes from the year in the yyyy-mm-dd format. And a perpetual source of bugs when inexperienced devs use the wrong year specifier (https://news.ycombinator.com/item?id=18762988 https://news.ycombinator.com/item?id=18762988). The biggest wart in the spec IMO is the (optional) T in 2021-02-26T09:24, which makes the datetime format much harder to read for humans. [1] https://en.wikipedia.org/wiki/ISO_week_date https://en.wikipedia.org/wiki/ISO_week_date

AlanYx 6y ago
The "week date" format (yyyy-www-d) in ISO8601 is IMHO why it's usually better to refer to RFC3339, which doesn't allow the week date format. So many people are unaware that the ISO8601 format allows "week date" and/or don't understand its quirks, and articles like this one, which don't even mention that ISO8601 dates can appear in this format, compound the problem.
- rswail 6y ago
  What about the Durations and Intervals? The "Week" format is great for planning purposes, because it allows a granularity between days and months with another whole number per year. Saying that a task will begin 2021-W08 and then defining the start of the week (ISO8601 says its a Monday), tells you exactly when it will start. Saying the task is 2021-W08/P4D tells you exactly when it starts and how long it will take. Or P4D/2021-02-25 says the same thing but in terms of when it will end. They're just as unambigious and just as useful.

lovelyviking 6y ago

I invented for myself this one: 2021-02-26_08-30-00_ And never looked back. Because since then I have no problems with dates anymore. If there is a need for 'ms' you can add them in the end or add more sections for more precision. For me it solves it.

lazyasciiart 6y ago
One day you'll need to read a date written by someone else.
- lovelyviking 6y ago
  Or perhaps one day you'll need to read this one :) If I meet another date format I convert it to this one when possible. For instance I setup this date format for MacOS in Settings->Language & Region->Advanced->Dates: this way: Short: y-MM-dd Medium: y-MM-dd Long: y-MM-dd_HH-mm-ss Full: EEEE,y-MM-dd_HH-mm-ss You just put those strings there and it should work. In terminal you can do it too: date "+%Y-%m-%d_%H-%M-%S_" or datetime=$(date "+%Y-%m-%d_%H-%M-%S_")

valenterry 6y ago

ISO 8601 contains durations and time intervals which are totally undervalued! (https://en.wikipedia.org/wiki/ISO_8601#Time_intervals https://en.wikipedia.org/wiki/ISO_8601#Time_intervals) E.g.: 2021-05-01T12:00:00Z/P2H They are so convenient. Ever stored a tuple of two datetimes to model a time interval? E.g. a meeting that takes place on 2021-05-01T12:00:00Z and takes two hours? Don't! Instead, store it as an interval: "2021-05-01T12:00:00Z/P2H" Or are you creating an API where a duration or a time interval is expected? E.g. "give me all sales in this time period..." Using time intervals for that makes it so much more easy for people to code against it and execute manual queries. For JVM developers, there is a library out there that has amazing support: https://github.com/MenoData/Time4J https://github.com/MenoData/Time4J For python developers, there is pendulum which supports most of the functionality.

em500 6y ago
I agree it's undervalued. Sadly too few people are aware that a standard notation for time intervals even exists, and external software support is very sparse (e.g. lacking in Pandas, R, most SQL implementations). Which leads to too many devs rolling their own buggy solutions for datetime arithmetic.
twic 6y ago
As of Java 8, the JDK also has support for ISO duration formats, via java.time.Period and java.time.Duration.
valbaca 6y ago
100% agree that it's undervalued. Was just in a software design meeting where they were trying to figure out how to represent exactly this: a time interval. I had to repeat "Just read ISO 8601 and use it" like a dozen times. "Bu-bu-but what if we want to represent a recurring..." READ IT. AND USE IT.
brewmarche 6y ago
Shouldn't it be /PT2H instead of /P2H?

young_unixer 6y ago

Tangentially related: I hate GNOME's approach at configuring formats. In their format settings, you have to pick a country and that determines the format of dates, time, numbers, and the unit system. Of all the countries, none of them has the sane choice for all of the fields, namely: ISO 8601 for dates and times with 24h (no AM/PM), metric system (or SI, whatever), and dot as decimal separator. You can have sane dates, but then you have AM/PM in the clock. You can have 24h clock, but then you have a comma as decimal separator, etc. Can we add a country "Saneland" with the sensible options for all fields? cause that's where I want to be from. Saneland: the imaginary place where we use reasonable standards and things work.

sebmellen 6y ago
This is one of my biggest gripes with GNOME, along with the incredibly stupid lack of thumbnails in the file browser.
- superzamp 6y ago
  And the way if forces you into a full-blown file search when you start typing letters and are just looking for files with that prefix...
  - hda2 6y ago
    I open a new terminal and tab my way to the file I want because it's quicker and less mentally-demanding than solving Gnome's UI puzzles. At least I used to until I had enough and switched to a different file manager.
- matheusmoreira 6y ago
  That still hasn't been fixed? It's been so long it's become an old meme at this point. People still mock Linux for it...
akvadrako 6y ago
Probably those are from the locales package? en-dk is the best one, it is Europe standard english which I think fits all your requirements for Saneland.

kstenerud 6y ago

ISO-8601 was a good early attempt, but unfortunately it has some negative points: - Only offset-based time zones are allowed (which are next to useless). - Omitting the time zone defaults to local time, which renders the time ambiguous. Defaulting to UTC makes much more sense. - BC dates are all offset by 1 ("-1" = 2 BC). I know the reasons for this, but this could have been moved to the implementation and not exposed to the user. - Lots of silly things like fractional-minutes and multiple ways to represent the same data bloat the spec and implementations. This is why I rejected iso-8601 and developed my own for https://github.com/kstenerud/concise-encoding/blob/master/cte-specification.md#temporal-types https://github.com/kstenerud/concise-encoding/blob/master/ct... Examples: 2019-8-5 : August 5, 2019 -300-12-21 : December 21, 300 BC (proleptic Gregorian) 12:05:50.102 : 12:05:50 and 102 milliseconds UTC 4:00:00/Asia/Tokyo : 4:00:00 Tokyo time 2019-01-23/14:08:51.941245 : January 23, 2019, at 14:08:51 and 941245 microseconds, UTC 1985-10-26/01:20:01.105/America/Los_Angeles : October 26, 1985, at 1:20:01 and 105 milliseconds, Los Angeles time 25192-11-01/03:00:00/48.86/2.36 : November 1st, 25192, at 3:00:00, at whatever is in the place of Paris at that time (global coordinates 48.86, 2.36)

jbj 6y ago

my birthday is at the end of the month, during a processing of a document for my US visa 10+ years ago, I was dealing with 2 different sites, one accomodating my local date formatting, and one fixed for the US standard. I was puzzled that I had been made 2 years younger when verifying my data, turned out my birth date of month was now month number 24+ of the year, pushing my birth ahead, and my birtb month had become my birth date of month.

_raz 6y ago

I like how the first paragraph ends with "I’m here to (hopefully) change your mind by introducing you to a lesser-known date format called ISO 8601." It seems so foreign to me, and most people i know, to use anything but ISO8601 or RFC3339. Might be, as with most things, that we here up in the Nordics simply are used to it.

antihero 6y ago

It is a good format for sorting, but misses the point of use. As humans, we want to read the most significant data to our use case first. The author confuses value to the reader with magnitute. In normal numbers, they happen to be the same thing. In most cases, we want to discern between days first, them months, then years. If you look at a list of dates: 2021-01-01 2021-01-02 2021-01-03 2021-01-04 You're just going to be seeing a heap of noise before you see the actual number you care about. If you consider that days are the most valuable, then months, then years, you get the UK/European format. 01/01/2021 02/01/2021 03/01/2021 04/01/2021

TeMPOraL 6y ago
> In most cases, we want to discern between days first, them months, then years. That really, really depends on particulars on your life. While I strongly dislike the US format of putting the month first, the irony is, the month is the most important datum for most of the dates I read with. Year is usually obvious given particular context (it's typically either the current one, the next one, or sometimes the previous one). Days don't matter for anything that isn't in the same month. I'd go as far as saying that months are typically the most important for most people in XXI century, then days, then years. But that's no problem for punctuated date formats in general. People don't read things linearly at letter level, they deconstruct tokens in a random-access way. Separators like - or / help clearly identify which part is which (compare how easy it is to read 03/01/2021 with 03012021), and there's no extra cost associated with reading off the part in the middle. The benefits of YYYY-MM-DD notation on top of the above are: - With all terms being fully expanded, dates line up vertically as well, which helps when dealing with stacks of documents or tabular data. - Being ordered by magnitude like normal numbers provides a Schelling point for interpretation[0]. That is, when a random person who wasn't exposed to much computing or internationalization before sees 2021-01-03, they will automatically assume that 01 must be the month, because writing YYYY-DD-MM would be dumb and inconsistent with how numbers are written in general. Yes, both of these apply to DD/MM/YYYY, but, YYYY-MM-DD also gets you sane lexicographic sorting, which the UK/European format doesn't. It's super useful feature not just when dealing with computers, but also when perusing any kind of date index. ISO 8601 dates work much like words in a dictionary, you can binary-search through them. -- [0] - https://en.wikipedia.org/wiki/Focal_point_(game_theory) https://en.wikipedia.org/wiki/Focal_point_(game_theory)

roelschroeven 6y ago

I wish HTTP would ISO 8601 for its dates, or anything sane in any case. Dates in HTTP headers are meant to be machine-readable, right? Then why use month names instead of numbers? Why include the day name? "Wed, 21 Oct 2015 07:28:00 GMT" is just silly. And that's just the preferred format; there are two other formats that are just as idiotic that recipients are supposed to understand. https://tools.ietf.org/html/rfc7231#section-7.1.1.1 https://tools.ietf.org/html/rfc7231#section-7.1.1.1

BoppreH 6y ago

I have a question for the timezone crowd: why does the ISO 8601 format include a UTC offset like "+09:00" instead of a more useful region name like "Asia/Tokyo"[0]? Take for example the timestamp "2025-07-20 13:30:00+09:00": - If it was supposed to represent a meeting in Asia/Tokyo and that region changes offsets (DST or political reasons), we don't have enough information to update the timestamp because it could also have been Asia/Seoul or other. - If a leap second is subtracted at 2025-07-20 13:30:01+09:00, we'll see that timestamp twice and it's now ambiguous which moment it refers to. - If a leap second is added at 2025-07-20 13:29:59.9+09:00, we'll never see that timestamp and now it's not a valid moment anymore. - Because of the regional offset changes and leap seconds between now and then, I can't reliably subtract that date from any other date to calculate durations. I'm struggling to think of a situation where this timestamp format is the correct one. Why don't we have "2025-07-20 13:30:00+09:00[Asia/Tokyo]" or even just "2025-07-20 13:30:00 [Asia/Tokyo]"? [0]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

sirn 6y ago
I think because it would defeat the portability of a timestamp because Asia/Tokyo isn't constant and you cannot lookup the offset without relying on external database that takes in ("2021-02-26 18:38:00", "Asia/Tokyo") as a parameter. Offset in zoneinfo changes depending on day of a year, and sometimes even hour of a day, and the database of timezone is constantly updated (latest zoneinfo is version 2021a). So while having 2021-02-26 18:38:00 Asia/Tokyo as a timestamp would more accurately represent the time, it would create another set of issues, namely requiring a database to look it up, and requiring to keep those database in sync in all systems in the world. Having both may be redundant because in that case you can't still trust the offset. There are alternative systems such as TAI64[1] based on TAI[2] that are meant to accurately represent the moment in time without being subjected to leap second (only account them on conversion to UTC). The main issue is TAI64 is not really human readable (e.g. @4000000037c219bf2ef02e94) and would still require database of leap seconds to accurately convert back to UTC. [1]: http://cr.yp.to/libtai/tai64.html http://cr.yp.to/libtai/tai64.html [2]: https://en.m.wikipedia.org/wiki/International_Atomic_Time https://en.m.wikipedia.org/wiki/International_Atomic_Time

deleted 6y ago

[deleted]

simon04 6y ago

Has anyone succeeded in configuring GNU/Linux to consistently output dates in ISO 8601 format? A partial solution involves... ls -l --time-style=full-iso git log --date=iso date --iso-8601=s # or date --rfc-3339=s export TIME_STYLE='long-iso'

fmajid 6y ago

Except `YYYY-MM-DD HH:MM:SS` is not the ISO 8601 date format, `YYYY-MM-DDTHH:MM:SS` is (note the T). Replacing the T with a space is a RFC3339 extension.

alkonaut 6y ago

I wouldn’t call ddmmyy “European”. Many countries use yymmdd (nordics, for example) which is the iso order. And the order in which alphabetical or numerical sorting works out of the box. Other than inertia/tradition there is really no excuse for shuffling around a date in any other way.

hanche 6y ago
In Norway, the current standard is dd.mm.yy. Before computers, it was d/m-yy (no leading zeroes). I come across yyyy-mm-dd once in a while, but it is sort of rare.

wankeler 6y ago

26 II 2021 Job done

joshspankit 6y ago

In my opinion, YYYY-MM-DD is the last unambiguous date format left. I hold the line, and I will die on this hill.

m463 6y ago

I was going to say this is a lot more readable than that other date/time format: 2021-02-26T12:25:04Z or 2020-01-30T03:14:15+05:00 but turns out its the same one

brnrr 6y ago

Here's an interesting date format most of HN probably haven't heard of; military date-time-groups[1]. 270009LFEB21 Translation: The 27th, 00:09, "L" timezone (+11, NATO timezone[2]), February, 2021. Advantages: - it's much more compact than ISO8601. - the most significant information is first; the date. - the second-most significant information is second; the time. - the timezone is a single alphanumeric character. - when military paperwork has a box at the top that says "DTG", everyone knows the format. - I'm pretty sure it's a standard across all NATO militaries. [1] https://en.wikipedia.org/wiki/Date-time_group#Military_Date_Time_Group https://en.wikipedia.org/wiki/Date-time_group#Military_Date_... [2] https://en.wikipedia.org/wiki/List_of_military_time_zones https://en.wikipedia.org/wiki/List_of_military_time_zones

nayuki 6y ago
I never heard of this before. It looks like an awful brain teaser, like an extension of the American middle-endian format to the extreme. ISO 8601: [YYYY][MM][DD][hh][mm][tz] (0 1 2 3 4 TZ) Military DTG: [DD][hh][mm][tz][MM][YY] (2 3 4 TZ 1 0)

mdip 6y ago

Date/Time is frequent topic[0] for me. Generally speaking, a lot of these issues are knowing when it's appropriate to use what format. When displaying a date to a user, you do it in their configured local time, and in their configured date/time format. I don't think the author is advocating changing that behavior[1]. Where the problem comes in is "how you store date/time values". Normally, I don't find myself arguing as to the format. Generally speaking, people default to ISO-8601 for log file naming (many probably not realizing that's what they're doing -- aiming only for a naturally sortable list). The places I tend to store dates (databases) define how they're stored, otherwise. That doesn't mean a developer isn't going to store the date in server local/user local time (and often make discovering the reference time zone impossible). Please don't do this. Store in UTC. I'm not sure why the author is so hung up about the ordering of the dates, but while I worked in telecom, I briefly had a boss that was really particular about that (I've worked for a few folks in the UK, only this first boss had hang-ups). The US ordering probably originates from the most common way dates are spoken in the US: "Januaray 17th". A year is less frequently necessary, but when it is, it's tacked on the end. I don't think anyone thinks the way we write dates is particular superior, it's just the way we've done it since we first learned about dates. One thing I learned when I started working regularly with non-US folks. Never use numerical dates. Even if you write it in the format they are comfortable with, if there's any ambiguity, they're likely to assume you wrote it in the US format. I started writing/abbreviating month names. I ended up altering the written order, as well "17th of January or 17 Jan" because that particular first boss jokingly-non-joked about how obnoxious the other way was. Everybody's got their tabs/spaces war, I guess! [0] OK, so it's more of a pet peeve. [1] While it would be nice if we all used the same date/time format in our day-to-day life, it's one of those things that I'll wager will never happen... and I'd argue that doing so would cause more problems than it would help.

lowbloodsugar 6y ago

What about the Y10k bugs?

jeff-davis 6y ago

Years before 0 or after 9999 are not defined in 8601 (there is some attempt to allow for them, but it's not really specified). Also, the lexicographic sorting would be ruined (if it isn't already by timezones).

gnulinux 6y ago

I prepend my filenames with soemthing like `YYYY-MM-DD_HH:MM:SS.sss` or if second is enough `YYYY-MM-DD_HH:MM:SS`. The `T` there makes it hard to read for humans imho.

scottmcdot 6y ago

I've been caught out by doing date comparisons in Spark SQL using string yyyy-mm-dd against string yyyy-mm-dd 00:00:00. It's easy to think that the trailing 00:00:00 will have no impact on date comparisons but it does! Lesson learnt: use substr(date, 1,10)

aimor 6y ago

My biggest complaint is that Windows doesn't allow ":" in file names. I just substitute "-", which is good enough, but not standard.

smiley1437 6y ago

Great format, but once 2032 rolls around everyone will go back to a 2 digit shorthand for the year. Because humans are lazy.

deleted 6y ago

[deleted]

therealmarv 6y ago

Even the xkcd https://xkcd.com/1179/ https://xkcd.com/1179/ does not mention or gets wrong that yyyymmdd is also right and allowed in ISO 8601. Especially useful when you add time. You don't e.g. want character ":" in your file name 20210226T205418 (local time here)

davidbanham 6y ago

A note from the front line. I actually use 8601 dates in a date-heavy consumer product ( https://clubman.app https://clubman.app ) and it’s hands down the feature I most consistently get user feedback on. It’s always “Why are the dates all American format? Can you change them to English?” And then I try to patiently explain that they’re actually international format. People seem to have internalised that any date format they find slightly unfamiliar is “the bad American one” I’m in the process of cutting everything I can over to “24th Jan 2020” style.

jamie_ca 6y ago
Another advantage to outputting 8601 dates is it's easy to mechanically parse - you can probably find some JS to rewrite the 8601 dates coming from the server into whatever the user's current locale is. Bonus points: if your timestamps are UTC, the frontend reformatting can even take timezones into account (such that an American and an Australian could correctly see different dates for the same timestamp).
- davidbanham 6y ago
  I did try rewriting dates into a user's locale as specified by the browser. The trouble there is that a lot of people seem to have that set to en-US rather than en-AU. So I still got a bunch of people unhappy that the dates were American!

CivBase 6y ago

> If you’re smart enough, you’ve probably also noticed that the American one makes no sense and is just awful That's simply not true. The American format is designed to reflect how we normally pronounce dates or write them out in long form (eg "September 11th, 2001"). The European format is also flawed. It's similarly divided into three tokens (day, month, year) but they are ordered so that the tokens represent greater magnitudes of time moving from left to right, big-endian-style. The problem is each token is a decimal number which is traditionally written in little-endian-style. So like the American format, you still need special understanding of the format to read dates and they cannot be trivially sorted. The ISO 8601 format is little-endian all the way through so it is trivially sorted. UNIX time is even easier to sort and compresses much better, but it's rather difficult for humans to read.

heurisko 6y ago
> The American format is designed to reflect how we normally pronounce dates or write them out in long form (eg "September 11th, 2001"). In the UK at least, we don't write or say dates in that order. With the exception of September 11th. I believe it's the same in German, 4te Juni etc.

itcrowd 6y ago

I have recently been inviting my American colleagues to meetings using times-as-American-dates format. In other words, proposing meetings to be on 02/26/21 at 25:23 (This example meaning February 26th 2021 at 25 minutes past 23 hours).

gr__or 6y ago

> a lesser-known date format called ISO 8601 is he being ironic? One of the things I love most about 8601 is it being supported by basically every* std lib (and definitely every library working with dates) * JS, Python, Ruby, PostgreSQL,...

Pinus 6y ago

Off topic, but I can't resist: Using Comic Neue with Comic Sans as fallback must be the typographic equivalent of russian roulette.

emergie 6y ago

Date formats are pure fun. ['en-US','en-IE','en-GB','en-ZA','de-DE','es-ES','nl-NL','pl-PL','ru-RU','cs-CZ','sv-SE','fi-FI','lv-LV'] .forEach(lang => console.log(lang + ': ' + new Date('2020-02-04').toLocaleDateString(lang, {day:'numeric', month:'numeric', year:'numeric'}))) en-US: 2/4/2020 en-IE: 4/2/2020 en-GB: 04/02/2020 en-ZA: 2020/02/04 de-DE: 4.2.2020 es-ES: 4/2/2020 nl-NL: 4-2-2020 pl-PL: 4.02.2020 ru-RU: 04.02.2020 cs-CZ: 4. 2. 2020 sv-SE: 2020-02-04 fi-FI: 4.2.2020 lv-LV: 2020.02.4.

justnotworthit 6y ago

> And the American format just makes no sense > Maybe the European date format is better because the elements are in the order of relevance? > ... when we’re talking about events occuring on a day-to-day basis, however I can think of numerous cases when the year and the month are more relevant I think that's the "sense" of the American one. It optimizes "metal sort" for month.

account42 6y ago

Having mm/dd/yyyy and dd.mm.yyyy wouln't even be so bad if people did not also write mm.dd.yyyy and dd/mm/yyyy and mm-dd-yyyy and dd-mm-yyyy and mm.dd.yy and dd/mm/yy and mm-dd-yy and dd-mm-yy and mm.dd and dd.mm and mm/dd and dd/mm. Of course even then, yyyy-mm-dd is best.