16 ms·
RFC 3339 vs. ISO 8601
- willis936 5y agoIs the timezone necessary to be compliant? My favorite ISO 8601 format is "%Y%M%DT%h%m%s%", but the table includes a "−Z" on the end and the "Now" column evaluates this as my current timezone. It says the list isn't exhaustive, but I'm just curious how often others actually embed the timezone rather than just passing around UTC.
- fanf2 5y agoOne of the aims of RFC 3339 is to eliminate the ambiguous variants from ISO 8601, so it makes the timezone obligatory. Timestamps without a timezone are in an unspecified local time.
- willis936 5y agoTimestamps with a timezone are in UTC.
- gerikson 5y agoIt's only needed for disambiguation. That said, I wish the page had actually taken the local time into account. As in your case the times on the page are in my current timezone (CEST) so the "Z", "00:00", "+00:00" is basically just decoration. ~~Even worse, in the intersection we have formats like %h:%m:%s+Z and %h:%m:%s+02:00 that show the same time simultaneously.~~ Edit: it is correct now.
- drdec 5y agoI'm in the America/New_York zone and I see the proper times for the values with "Z" vs the values with "-4:00". That is, they are off by four hours.
- deleted 5y ago[deleted]
- lborsato 5y agoI’m in America/New_York as well and I see them correctly. I think your computer’s time zone may be incorrect.
- Macha 5y agoIf you're looking in the backwards direction and its important what local time in a different location it happened, that's the use case for offset date time. Maybe you're investigating traffic patterns in which case it can be clearer when it's 6pm local time rather than noon utc or whatever. Embedding that in the returned timestamp can save another field. However, for the forward looking/scheduling one one, if you want it to keep the same time across timezone/DST policy changes, you need to the full on timezone designator (i.e. America/New_York), not just the offset or short, ambiguous timezone code (EST). There's no allowance in ISO 8601 for this, so you need a side channel like another field to communicate this. I've seen other date formats do something like 2021-10-11T12:13:14[America/New_York] to allow for this. Once you do this, it probably makes sense to elide the offset to avoid the risk of consfusing mismatches between it and the timezone.
- sanderjd 5y agoIn my view what's best is to always pass around utc but include the Z to make it explicit that's what you're doing. It's a very succinct way to represent that and can be very valuable to disambiguate so I think it's worth the extra character.
- midasuni 5y agoSometimes you are defining a date by the local time. I have a meeting on June 13th 2026 at 15:00 london time. This could be 2026-06-13 14:00:00 Z But if the U.K. drops summer time, or makes it double summer time, the meeting will still be 1500 london time, but the UTC time might change to 1500Z or 1300Z
- pletnes 5y agoThe use of colon in timestamps is incompatible with several filesystems and this just drives me nuts.
- Springtime 5y agoMy workaround has been to use alternate Unicode for colons[1] in filenames in Windows, along with similar substitutes for other illegal characters. For ease of input I use Autohotkey bindings (in this example: Alt+colon). [1] '꞉' (U+A789). On my Windows systems the default typeface renders this identically to a regular colon.
- dvh 5y agoMe too, I'm usually using 2021-10-24--13-07-59
- jacobmischka 5y agoI use `--` to represent an en dash for date ranges (some_report_2021-01-01--2021-12-31). I don't use times nearly as often, but I separate date from time using an underscore in those instances.
- LinAGKar 5y agoBy "several filesystems", you mean Windows? NTFS can handle it, but Windows can't (presumably due to using it for drive letters).
- rogerbinns 5y agoNTFS can't have colons in filenames because they are used to name alternate data streams. https://docs.microsoft.com/en-us/sysinternals/downloads/streams https://docs.microsoft.com/en-us/sysinternals/downloads/stre...
- boondaburrah 5y ago':' was the traditional directory separator on Macintosh systems before OSX, therefore it can't be used on HFS+ either. I remember there being some FS funk when OSX came out since it was very common for people to put dates in their filenames using slashes, and well, UNIX doesn't like that. I don't know what APFS does.
- TacticalCoder 5y agoI never really thought about six-digits years (I don't really understand what is meant by "by mutual agreement"): is this something in use today and by whom? Who needs six-digits years and only six digit years? I mean: if you're projecting stuff in the future (like, say, continental drift), you'll be stuff at year 99999 and have the exact same problem of wrapping around back to zero when you'd need year 1000000 no? Or is it "infinite": as in, the spec allows for 8-digits years, 10, etc.?
- gerikson 5y agoI've seen 5 digit years in use online in some places, but not 6-digit (so far). Maybe it's influenced by the Long Now project? For long timescales (geological deep time) I believe using SI units are more appropriate: https://en.wikipedia.org/wiki/Year#SI_prefix_multipliers https://en.wikipedia.org/wiki/Year#SI_prefix_multipliers
- cmclaren 5y agoThe spec permits more than 4 digits for 'year' by mutual agreement. This is called 'expanded representation'. There is no limit to the number of digits, but parties need to agree on how many additional digits will be used to avoid ambiguous representations. Consider that +002021001 could represent: a) "Oct 1, 202" as a calendar date (proleptic Gregorian), in 'basic' format (i.e. no "-" separator), 5 digits for year. b) "Jan 1, 2021" as an ordinal date, 'basic' format (i.e. no "-" separator), 6 digits for year.
- em500 5y agoThis is very neat, but maybe not completely accurate. "2021-10-24 11:02:03Z" is outside iso8601 in the figure, but I think it's valid iso8601. True, "T" is the One True date-time separator in iso8601 (IMO its biggest wart, as it looks awful for human eyes: "2021-10-24T11:02:03Z"). But according to the draft standard[1], page 21: > By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard [1] The actual ISO standard is not freely available, but the Library of Congress has free draft standards: 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...
- rdpintqogeogsaa 5y agoIt's correct. Omission means 2021-10-2411:02:03Z, not replacing it with a space instead.
- grey_earthling 5y agoOmitting the hyphens and colons is allowed too (IIRC), so I suppose omitting the T is intended for cases like 20211024110203Z — which IMO is a sensible format when there's no ambiguity that this is a date-time.
- jfrunyon 5y agoThat's a sensible format only for interchange - humans need separators to read it...
- kbenson 5y agoThey don't need it. It makes it easier, but if you know it's a date and time format, it's pretty easy to read as long as you take care to keep track at which characters your looking at. Justlikehowinmostcasesepacesmakeiteasiertoreadsomethingbutaren'trequired.
- jacobmischka 5y agoI like the concept of ISOs in general, but I personally prefer RFC 3339. The space makes it so much easier to read at a glance, and I can't imagine it makes parsing much different algorithmically?
- smitty1e 5y agoSpace characters affect processing in shell scripts, so one manages them closely, along with colons, as noted elewhere.
- remram 5y agoIn what context would you prefer ISO over RFC? The fact that ISO standards cost hundreds to read and apparently change over time, while RFCs are openly available and get replaced if necessary, makes it hard for me to see ISO as more than a crutch. If there's an open standard, I'll use that, and people will actually know what I'm talking about.
- jacobmischka 5y agoI agree with everything you said. I guess I just naively like the idea of an international standards organization in theory, though I suppose that's also essentially what the IETF is too.
- venthur 5y agoI'm surprised that neither of them has standardized the quarter, i.e. 2021-Q1. This is fairly common in business.
- iwwr 5y agoQuarter depends on reporting periods, or fiscal year, which does not match calendar year everywhere.
- dotancohen 5y ago> which does not match calendar year everywhere Yes, this is the reason that ISO-8601 ranges are not sufficient and a Quarter indicator is necessary.
- marcosdumay 5y agoThe problem is that if you carry the string '2021-Q1' across countries borders, the days it represents change. That makes for a very bad time interchange format. I agree that this feature makes quarter indicator necessary. But it also makes it required that the string is something more complex.
- dotancohen 5y agoIf you carry the string '2021-10-24' across countries borders, the moments in time that it represents change as well. That makes doesn't make it a bad time interchange format for certain use cases, though. Just like everything else with time, one must be aware of caveats. Those include timezones, leap periods, culture, DST, formats, legislation (modern and ancient), etc.
- remram 5y agoBut it overlaps. It's off, but less than 100% off. "2021-Q1" can be a completely different and non-overlapping range between regions, and even between companies in the same region.
- bla3 5y agohttps://datatracker.ietf.org/doc/html/rfc3339 https://datatracker.ietf.org/doc/html/rfc3339 says that rfc339 is a"profile of iso8601" -- shouldn't it be a true subset? Also, I read through that RFC several times and didn't find where it allows replacing 'Z' with space. Can anyone else find it?
- rdpintqogeogsaa 5y agoSection 5.6: > NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.
- bla3 5y agoThanks! Seems to contradict sections 5.2 and 5.5 in spirit...
- hendry 5y agoRE time standards, I always thought it was interesting how WHATWG took a subset of ISO 8601 since ISO went off the rails wrt poorly defined complexity. https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#dates-and-times https://html.spec.whatwg.org/multipage/common-microsyntaxes....
- gorgoiler 5y ago…and none of these do timezones properly! If your birthday party is: 2022-05-01T16:00+1000 …but tomorrow’s government abolishes daylight savings time, your birthday event has to change to: 2022-05-01T16:00+0900. If you’d just said: 2022-05-01T16:00 Asia/Eastern_Siberia …you’d be fine and everyone will show up at the right time.
- computerfriend 5y agoIf your birthday party is 2022-05-01T16:00 Asia/Eastern_Siberia but you said 2022-05-01T16:00+1000 instead, then you made a mistake. If it's really at 2022-05-01T16:00+1000, then it doesn't matter what DST policy changes occur.
- gorgoiler 5y agoThe point of a future timestamp + tzdb timezone is to twofold: 1/ my birthday party will start when my watch shows this local time and date 2/ my local time and date are dictated by the legislative body responsible for this geographic area.
- kstenerud 5y agoThis is the biggest reason why I had to develop a new time format for Concise Encoding :/ https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#temporal-types https://github.com/kstenerud/concise-encoding/blob/master/ce... https://github.com/kstenerud/concise-encoding/blob/master/cte-specification.md#why-not-iso-8601-or-rfc-3339 https://github.com/kstenerud/concise-encoding/blob/master/ct... ISO 8601 and RFC 3339 are only useful for times in the past (which works fine for most internet protocols because they're only interested in recording events).
- kortex 5y agoI was going to give you the usual "now there are 15 different standards" but this is actually really well thought out. How does it handle leading zeros in the year, like Long Now likes to do? https://blog.longnow.org/02013/12/31/long-now-years-five-digit-dates-and-10k-compliance-at-home/ https://blog.longnow.org/02013/12/31/long-now-years-five-dig...
- emilfihlman 5y agoStill missing the best %F %T %z (Ie %Y-%m-%d %H:%M:%S %z) Though adding nanoseconds is also recommended.
- est 5y agoon Python 3.6, the %X gives 14:09:44. Is this a intended or a bug?
- emilfihlman 5y agoImho that does sound like a bug. %X should give a dot separated time, like 22.47.30 You can live test according to Linux man-pages project, release 4.14 at emil.fi/p/strftime (sorry about the css, it seems it's broken a little bit, you can use the "use desktop site" selection to have it behave better).
- vslira 5y agoAs someone who frequently works with datetime data, I always felt that in the format YYYY-MM-DDTHH:mm±ZZ:ZZ, it should read "this local time plus the timezone offset gives you utc", not " utc plus the timezone offset gives you this local time", so basically invert the signal from how it is now.
- gnulinux 5y agoBut then they wouldn't be lexicographically sortable.
- Waterluvian 5y agoDoes anyone know of a website that lets you paste in date strings and it will show you all the possible formats they adhere to along with their format strings? I often come across a string and don’t recognize the format and would love to just supply a bunch of examples and make a best guess.
- samhw 5y agoThis site is notionally devoted to Unix timestamps, but it covers a few popular formats: https://www.unixtimestamp.com/ https://www.unixtimestamp.com/
- NelsonMinar 5y agoNote that Python still lacks any way to parse these dates in the standard library. You have to use a third party library to parse them. You might think `datetime.fromisoformat` parsed ISO dates but you'd be wrong; it doesn't support the trailing Z or any other form of timezone information. The docs are clear about this, and the developer discussion I've read basically boils down to "it's too hard to parse ISO dates so we didn't do it here." This discussion has been going on for years. https://stackoverflow.com/questions/127803/how-do-i-parse-an-iso-8601-formatted-date https://stackoverflow.com/questions/127803/how-do-i-parse-an...
- macintux 5y agoPlus the naive date times that seem to pop up by default. Frustrating.
- Dunedan 5y agoCan you elaborate on this? Parsing ISO 8601 formatted dates doesn't result in naive Python datetimes: >>> datetime.fromisoformat("2021-10-24T20:17:41+02:00") datetime.datetime(2021, 10, 24, 20, 17, 41, tzinfo=datetime.timezone(datetime.timedelta(seconds=7200)))
- NelsonMinar 5y agoYour example demonstrates I'm wrong with isoformat not supporting any timezone info. Sorry about that. Given it can handle +02:00 I wonder why they don't just add support for z and Z and instantly cover 95% of the world's JSON data?
- macintux 5y agoSorry, was on mobile and didn't elaborate. Was referring to datetime.datetime.now(); why can't it incorporate the local timezone?
- Dunedan 5y agoWell, it can, it's just not the default: >>> from datetime import datetime, timezone >>> datetime.now(tz=timezone.utc).astimezone() datetime.datetime(2021, 10, 25, 19, 58, 34, 51668, tzinfo=datetime.timezone(datetime.timedelta(seconds=7200), 'CEST')) Or if you want to use a specific timezone: >>> from datetime import datetime >>> from zoneinfo import ZoneInfo >>> datetime.now(tz=ZoneInfo("Europe/Berlin")) datetime.datetime(2021, 10, 25, 19, 58, 34, 51668, tzinfo=zoneinfo.ZoneInfo(key='Europe/Berlin'))
- yeetaccount 5y agoAll this just makes it clear to me that we need a time standard which addresses all the problems and of ISO8601. It’ll be painful until it’s universally adopted, but once it is we’ll be in timekeeping heaven.
- iimblack 5y agoIs there a reason to not just use Unix timestamps? That’s how I’ve been passing datetimes in my api and storing them in my db.
- kbenson 5y agoAs long as you're sure they're all based on the same start time and not off by +/- 12 hours, no. One of the reasons a UTC+TZ format is useful is that it makes clients be explicit about this. This may or may not be a problem you need to worry about in your API depending on use and clients. For example, if you're only ever sending times and not accepting them, you can just define that the epoch you return is based on UTC or locally and let clients real with it. If you don't care about pre-epoch times, then it's a compact and fine representation for the DB, single they all have easy conversion functions to their internal formats
- zestyping 5y agoBecause the digits are of varying widths in the standard Apple system font, the ticking seconds cause the date strings to jiggle back and forth and the table column widths to jiggle as well! However, you can use CSS to select the fixed-width variant for digits. This is a perfect example of a use case for: * { font-variant-numeric: tabular-nums; }
- merb 5y agodo you now whats ridiculous? that we germans (and europeans) also use the iso 8601 but it's still allowed to use din 5008 and the european date and time notations... WHY??? it's so stupid to use dd.MM.yyyy, it's worse in every way to yyyy-MM-dd. worse than that the old notation is preferred in most official documents..... WHY....
- tgsovlerkhgsel 5y agoBecause unless you start fining or imprisoning people for using the wrong date format, people don't care what you write in a law book and will continue to use what they're used to if it works well enough. Allowing DIN 5008 simply acknowledges reality. Not acknowledging reality is a good way to make people decide that whatever is telling them they're doing it wrong is just "ivory tower" nonsense and should all be ignored at best, possibly actively opposed.
- xdennis 5y agoWhen using yyyy-MM-dd, I've had two people comment that they'd prefer if I didn't use American dates.
- Zekio 5y agoI keep hoping the whole world will switch to a single timezone utc, that way so many things would be simpler
- tgsovlerkhgsel 5y agoThe one big failure of RFC 3339 is that it doesn't specify the actual rules for the separator: Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character. Is separating it by a tab valid? A tilde? An underscore, as this website shows? Since this is so underspecified, there will be receivers that accept only T, and others that accept the T and some arbitrarily chosen character set. The ABNF only allows T. I don't know how a standard that was specifically written to resolve the issues resulting from such ambiguities ended up with such a crucial issue.
- mikl 5y agoIn short, RFC 3339 has all the useful formats we think of when we invoke ISO 8601. The ISO standard has those too, as well as a seemingly endless list of additional obscure and esoteric formats almost no one uses.