I find it weird that there's no way to specify a future date/time with respect to a specific timezone, e.g. Europe/London.
I don't think it's unreasonable to want to be able to specify a meeting in London, on July 1st 2030, at 6pm local time - no matter what happens to UK timezones between now and then.
The UK currently uses Z+00:00 from November to March, and daylight savings of Z+01:00 from April to October (roughly)[0]. But it's possible that between now and 2030 they might adopt Central European (Summer) Time[1], or retry British Double Summer Time[2], or scrap daylight savings entirely. Therefore, what happens to 6pm with respect to any given epoch might vary wildly between now and 2030.
But it would be nice to set a calendar event for "6pm London time", whatever London time happens to be when the event rolls around. But there's no standardised interoperable way to say "2030-07-01 18:00:00 Europe/London".
There's currently a draft document for such a format [0], called IXDTF (the Internet Extended Date/Time Format). It allows you to specify a timezone (as a tz name) in brackets following an RFC 3339 string. To give a local time, you have to specify your best estimate of the UTC offset alongside the bracketed timezone. For instance, "2030-07-01 18:00:00 Europe/London" would be "2030-07-01T18:00:00+01:00[Europe/London]".
If the UK changes its rules before that time, then the timestamp becomes "inconsistent" (see section 3.4). The behavior on an inconsistent timestamp is left for the application to decide, but if a ! character is included within the brackets before the timezone name, then it's at least obligated to detect the problem instead of blindly following the UTC offset:
> In case of inconsistent time-offset and time zone suffix, if the critical flag is used on the time zone suffix, an application MUST act on the inconsistency. If the critical flag is not used, it MAY act on the inconsistency. Acting on the inconsistency may involve rejecting the timestamp, or resolving the inconsistency via additional information such as user input and/or programmed behavior.
This extended timestamp format is used in the proposed Temporal library for JavaScript [1] (though I'm not sure if it supports the ! character). The ZonedDateTime.from() parsing function [2] takes an optional "offset" parameter to allow the user to control which part of an inconsistent timestamp takes precedence. It also supports simply omitting the UTC offset and using only the timezone, but it warns that this is ambiguous for times in the repeated hour during a DST transition.
If the 'Asia/Manila' timezone changes to the 'Asia/Shanghai' timezone, the old timezone will still exist, but a rule will be added to indicate the change.
The tz name here is a specific name in the tzdata database, so it's quite easy for that database to never remove any entries, but to rather deprecate them or link them to new ones, if appropriate.
Yes and then you'll have old source code that still uses the old names to indicate time-zones and newer source code that refers to all the newest names of time-zones.
No? If the UK decides to stop doing DST or synchronize when they do DST with North America I still want to have my meeting at 6pm local time. Not have that meeting be 5pm or 7pm for some reason.
This time description in the indicated timezone, at the instant it is correct? (Ignore updates, I mean the time I said. E.G. The doors open at 8am every day.)
An indicated end of a duration, such as the period of time a mass of decaying radio-isotopes are valid for the sensor during? (Offhand, no consumer equipment comes to mind, but for an extremely sensitive calibrated sample it could matter and this is a contrived example.) Exact moment in monotonic time. (What about stretchy leap seconds too?)
Something between the two extremes?
Most humans probably want a default of something like...
"Looser more common use time unless I get more specific." So if a TZ is included, it isn't a fixed moment, but whatever specifier is the valid moment as that moment passes. Convert it to an absolute monotonic value at that time to record the event and not just the specification of when to capture the event's passing.
E.G.
Unix time Epoch was 1970-01-01 00:00:00~Z with an absolute reference value of 0s
DATE RoundedHour~US.EST => Actually is EDT but most people don't use that notation, and congress changed when DST happens yet again without abolishing it too, and this happened last year before the change but the event did run from Noon to 9PM with these event moment second values...
It would simply mean the time which is intended. It’s true that the instant isn’t known until it happens (or however much leeway precedes a TZ change). It’s generally always better to record intent, than to be smart and translate inputs to something else.
To map to a specific instant in UTC time, you use the string plus a db. The db can change in the future, and that’s ok. You simply update in the presentation layer in case you have any “2h left” strings or calendar entries. Note you should NOT store the mapped instance in a db before the event has occurred (and even then it’s unnecessary since it’s fixed).
I really don’t like the “inconsistent” mutable property and agree with parent that offset should not be part of the format. That would make it extremely easy to overlook or misuse.
Yes, you’re missing something - geography. “Local time” doesn’t include a frame of reference. If you want to have a meaningful representation of local time you need syntax to specify where, probably Lat/Long.
Then, periodically, the computer can look up the lat/long to see what the rules are there for time, and compare vs the target time.
But even THAT doesn’t solve the problem, because you probably don’t want the computer in a tight loop of looking up location rules for time and checking time. But if you do it periodically then there is a nonzero chance that you will miss the event because the rules changed since the last check and the current check happened after the event.
And you can’t just use the city names for time zones (e.g. “Europe/London”) because only a very small number of places have such names, and because they really refer to a combination of time zone and DST rules, not to a city, they just choose representative cities.
Finally, ISO 8601 does support durations, which RFC 3339 does not, so ISO seems more useful in that regard, but durations are not relative to any epoch.
However I'm saying that the solution should be radically different and much more user focused.
There is a difference between a description of when to capture a moment (which should favor the way the normal person describes moments) and an absolute moment event.
I think you want it more specific than a timezone.
For example, instead of London, suppose you wanted to meet in Glasgow, Scotland, on July 1st 2030, at 6pm local time.
Currently, Glasgow in is timezone Europe/London.
However, it is not unimaginable that in that time, Scotland could hold another referendum on independence and either join Central European Time, or create Scottish Standard Time.
The problem is that we don’t know what the timezone identifiers for hypothetical future timezones will be. Meaning, there would be no automated way to associate those future-date-time values with the correct timezone once the new timezone is added to the tz database.
One could imagine using geo coordinates or similar, but the mapping from those to timezones (or from/to zip codes or area codes) is already not precisely defined.
If you use city names, those might also be split/merged (Berlin) or renamed (Constantinopel).
If you use coordinates, make sure to take into account continental drift. You could use a plate-local coordinate system (e.g. British National Grid for Great Britain) so you only need to take into account deformation.
What about storing current geo coordinates and a timestamp of when they were recorded? I feel like that should be enough for a theoretical future system to adjust mapping for continental drift.
This whole discussion highlights the point that timezones etc. are relatively arbitrary.
Often the "time" isn't as important as the events that take place at a given time.
E.g. 6pm is a reasonable dinner time on the west coast of the US, but dinner doesn't start for many people in Buenos Aires, Argentina until after 8pm [0].
And then they change the calendar. (It has already happened in several regions when changing from Julian to Gregorian calendar. You don't know what calendar will be used at that region in the future)
What time zone people use at a given location is not even a function of geographical location; you plausibly also need to know language, culture, political affiliation, and/or employment status.
What is the issue with taking in a time format which people use at the current time, then convert it to coordinates + unix timestamp for definitive time and using it instead?
A link was added from "Europe/Kiev" to "Europe/Kyiv" in the included-by-default backward file [0], so that any user that doesn't exclude that file will simply treat the old name as an alias for the new name.
There are a few kinds of entry in the tz database. Europe/Kiev is now a Link entry to Europe/Kyiv which is a Canonical entry. Europe/Kiev used to be a canonical entry. What's interesting is there's a lot of thoughtful commentary about changing the name and handling the annexation of Crimea long before Russia invaded Ukraine
> timezones have precise boundaries that cover the whole earth, no?
Not only is that not true, but there are places on the earth where one country may think the timezone is X, but in another country it is illegal to claim that the timezone is X.
This happens most notably with China, which defines the entire country to be in a single timezone, and is engaged in multiple border disputes.
Similarly for many disputed territories in Antarctica, with the added fun of "the south pole region is special". But of course that is a very marginal topic.
A triple (Lat/Lon/UTC Date) <-> TimeZone at the very least.
Time zones are political | * social* especially in the twilight zone between two otherwise well defined zones.
If a country is mostly in TimeZone X then often an extrusion that goes well into TimeZone Y will remain with clocks aligned to TZ-X unless some local political change is made (to be more or less sensible).
and note that cities have changed time zones (not daylight savings changes, actual changes to core time zone) in the past and will almostly certainly do so again in the future.
> However, it is not unimaginable that in that time, Scotland could hold another referendum on independence and either join Central European Time, or create Scottish Standard Time.
Or be in the middle of a political dispute, with different times being used depending which side one is on, like Xinjiang. So just knowing the place and local time isn't enough.
Solar noon or clock noon? What happens if the full moon is on Tuesday? Will that Tuesday count towards the third? Even if the full moon is at 23:59 (23:59 in which timezone)? Do you use solar equinox, or the Julian equinox, or the Gregorian equinox?
I wonder what the downsides would be in a time model that is indicated by a normalized global value for the current longitude where the sun is at meridian.
I think it's reasonable to estimate the future time based on the current published rules. You don't need to guess at the probability of future published rules, but you do want to have sufficient information to reevaluate the published rules.
This is why storing UTC dates for future events is insufficient: if the event is actually specified in local time, the date is incorrect when the time zone rules are changed. But storing the time zone is insufficient if the time zone that applies to the event also changes; you also need to store enough information to reevaluate which time zone is applicable.
Of course, it can be difficult to gather this information in a user friendly way, so you know, compromises.
Even on the surface of the Earth there could be ambiguity. Some places have moved up to four meters in GPS coordinates after an earthquake. In Amsterdam that could be the difference between a war memorial and a brothel.
How: 6PM local time could mean Zulu+6 or Zulu+3 or anything else if local timezone offset changes via legislation. The best way to do it would be to say "X seconds from the time this message was sent"
> 6PM local time could mean Zulu+6 or Zulu+3 or anything else if local timezone offset changes via legislation.
That’s the point. Normal people think about time based on their local time. If they agree to meet someone at 3pm on a day in the future, that normally means turning up on that day when a local clock on that day reads 3pm. If local time changes offset from UTC, then the meeting implicitly also changes.
I’ve personally yet to meet someone that reschedules all their appointments every time day light saving (or the inverse) rolls around. Just make sure their appointment times in UTC don’t change.
+6 or +3 is irrelevant to the scheduler when they're setting the meeting time: they want it to be 6pm regardless of any time zone changes in the future. So they deliberately do not store the UTC offset with that time. They only store the geographic location.
Then when the meeting time is approaching, the software can figure out what time zone (and UTC offset) applies, after taking account any time zone changes that have taken place in the intervening years, and appropriately set reminder notifications.
If they were to store "X seconds from the time this message was sent", then any time zone change would likely make it not fall at 6pm on the target day, so that's not what they'd want.
"X seconds from the time this message was sent" would certainly not hit 6PM local time if the local timezone offset changed - unless you also update X every time it does.
> there is no difference between local time and "offset from UTC"
The difference is between applying the UTC offset for a future event using present rules. What we are saying is you should not do that because the rules can change.
I ask you today that we meet at 3PM on January 24th in 2026, at the train station in Berlin.
In my paper calendar book for
I mark the date January 24th 2026 with the following note: “meet jvanderbot at 3PM at the train station in Berlin”.
I carry this book with me for the next few years.
Meanwhile, you decide to be modern so you store a note about the meeting in a database. In doing so, you convert the information into a UTC offset for that future time. But you are using current rules for today, which may change.
And then when the day arrives, there has been political changes in the meantime that made it so that the utc offset is different.
Because you converted to utc offset ahead of time, your representation of the time no longer maps to “3 PM” but instead to let’s say “4 PM”.
I show up at 3 PM local time, as we had agreed. But you are nowhere to be seen because in your digital calendar the meeting appears to be for “4 PM”.
This is what we mean when we are talking about the problem with converting a local time to a UTC offset a long time ahead.
Local time has no notion of a UTC offset. Local time is just "9am on August 31, 2024". It's up to the application's implementation details to pair it with a physical location (e.g. some lat/long in London). The app would then have to (as the event date approaches) resolve that into something more computer-clock-understandable; that is, it would have to say "this lat/long is located in timezone XYZ, which has offset ### for that date", so it could tell the OS's notification service to pop up reminders at the appropriate times.
> But it would be nice to set a calendar event for "6pm London time", whatever London time happens to be when the event rolls around. But there's no standardised interoperable way to say "2030-07-01 18:00:00 Europe/London".
The only gotcha about such a thing is that there are ambiguous or impossible timestamps: 2023-11-05 01:30:00 America/New_York — that's one of two different times.
For calendaring, it would make sense, since "same wall clock time regardless" is what most people want¹; there might be some UI difficulty/challenges to handle the weird times, and maybe one might want to have a way to specify a disambiguation in the syntax.
Thankfully for calendaring those are usually in the middle of the night, but I've literally seen this happen in my career.
¹though once you invite the first person in a zone that doesn't do DST madness, note that this causes the calendar time to wobble on their calendars. Some of my international coworkers have to put up with this.
If I want a meeting at 9AM MST (Mountain Standard Time, which Phoenix observes year-round) then, when CA is on PDT (Pacific Daylight savings Time), they have the meeting at 9AM local time.
But when CA switches to PST (Pacific Standard Time) the meeting shifts to 8AM for the people in CA.
But if the people in CA lead, and always want the meeting at 9AM local time, then the meeting for the people in Phoenix will move from 9AM to 10AM and back.
This is why I prefer, and try to use, "<time> <fine-location> time". Like: "Friday 6:30PM Vancouver time" and a world-clock to keep track of when that is. The website time.is is very useful for this.
This takes a bit more effort, but it is less ambiguous and saves you from having to deal with the insanity that is time. DST switching will still cause issues but, as long as you're not the one cursed to implement that software, it should be fine with advance warning.
I know it works both ways, too, but probably would be better for the DST observing zone to deal with the effects of DST, instead of foisting such side effects onto our international friends.
In the OP's example, 2023-11-05 01:30:00 America/New_York, 1:30AM occurs twice as at 2:00AM the clock rolls back to 1:00AM. Normally this is resolved by including a disambiguating timezone, EDT (first 1:30AM) or EST (second 1:30AM). But if there's no timezone indication to accompany a geographical location, there's no way to disambiguate the time.
If there's no flag indicating DST. America/New_York is the timezone designation.
Part of what makes TZ discussions incredibly difficult is that people play fast and loose with the terminology.
I think the person you're responding to is simply saying that if you made the meeting in a non-DST observing zone, the meeting time would still wobble in a DST-observing zone. (I'm not sure why they're noting it, because my comment also clearly spells that out, too, albeit in reverse. But yes, it works both ways.)
Right, to pick an actual time stamp for a particular local time in a particular location, you need to first choose at what time stamp to resolve the time offset for the location. Then in that time offset you can unambiguously map the localtime to a unique time stamp.
As well as what wrs said in a sibling comment, iCalendar does not have a way to specify the location of a meeting in a machine-readable way that can be turned into the timezone for that location.
Sadly, iCalendar is very much tied to using timezones for locations. I expect that if/when Europe finally gets round to abolishing DST, there will be some significant changes to the timezone boundaries, and as a consequence, much hilarious calendaring failure. Dunno if it will affect as many people as the 2007 DST changes in North America, which caused a lot of extra work for people running Microsoft Exchange, because it was designed assuming that timezones never change. And this design error carries over to iCalendar, tho (apart from tz boundary changes) it is better than it was.
Yup. Similarly with the time zone aware Rust crate “chrono” you also have datetime representations for local time called “naive” datetime to store date time without time zone.
And likewise in PostgreSQL you can store timestamp without time zone.
Combine that representation with lat/long gps coordinates and you have what you need for scheduling future events at specific locations regardless of changes in time zone names and offsets.
Not quite — that requires you to find the time zone locality out of band somehow. The request is to have a standard way to store the time zone (not the current offset of the time zone) in the same string as the date/time.
But if I send that to someone who is in a different timezone, e.g. in America/New_York, will it put the event at 6pm London Time in their calendar, so that they can videocall in at whatever time that is where they are?
The ical format allows dates like DTSTART;TZID=Europe/London:20230901T201000
Whether your calendar software will let you choose how it expresses the timezone and whether the recipient's calendar software will store it that way is another question...
Google Calendar does, at least. It even supports representing events that being and end in different timezones (like a plane flight or a cross country trip)
You want three pieces of information, a date, a location and a local time. Note that I do not think you actually want a time zone, what if you are not in London and that place gets moved into another timezone?
All our common date time formats are intended to represent a specific point in time and this you just do not have in your case. But it is actually not too uncommon that date and time specifications have a non-trivial structure, think a meeting on every last Friday of the month or a monthly meeting series starting on January 31st or two days before the end of each quarter.
I would guess trying to come up with a standard that covers all the things people could come up with, would become quite complex quickly. So if simple dates, times or instants are not good enough, you are probably on your own, make some structure with all the required things.
> You want three pieces of information, a date, a location and a local time. Note that I do not think you actually want a time zone, what if you are not in London and that place gets moved into another timezone?
Theoretical arguments are nice, but in the real world, meetings are regularly scheduled were one or all people aren't physically at the location, say the company's headquarters, but the local time zone and its DST shifts are obviously still respected.
Those are two different things, either you want local time at some location or in some time zone, just pick what you need or want. And going one step back, who really has to schedule things to a specific time so far into the future that uncertainty about time zone changes become a valid concern? There are certainly things like a space probe arriving at Pluto in a couple of years, but in such cases you will not care about the local time in London. Or a long running construction project, building some tunnel for two decades, but who would schedule the opening ceremony to a specific date and time two decades into the future?
Many regular events are scheduled "indefinitely" into the future. Do you really think that when the US changed its DST rules a couple of years back, any of the regularly scheduled weekly meetings were happening according to the old rules?
Appointment series were the example that I gave earlier where you will have to use some more complex data structure than a simple date time value and corresponding logic to get it right. You can obviously not find the correct instants for a weekly meeting by repeatedly adding 168 hours to the instant of the first appointment. But this thread started from specifying a date and time of day in some place far into the future and I do not think an indefinite appointment series qualifies for this. Your scheduling application would most likely store something like every Tuesday and 13:00 and figure out the actual instants as needed, for example to show a reminder. And as it received updates about changed daylight saving time rules, it would recalculated the instants.
One idea I experimented with for this was to use airport codes. Airports are the approximate correct frequency (the kinds of political entities that might make decisions about timezones usually have an airport), quite recognisable to people familiar with the relevant area and have an established short code and canonical list.
There are disadvantages too of course, one of which is overlap between airport codes and currently existing timezone codes. This led me to discover a couple of airports that have the same code as their timezone.
Not to mention, there exist airports that are jointly administered by multiple country. One example I know of is EuroAirport Basel Mulhouse, located a few kilometers away from the meeting point of the French, German and Swiss borders. It is located on French soil but administered by both France and Switzerland and has three airport codes: MLH for France, BSL for Switzerland and EAP as a neutral code. The national codes could be used as proxies for timezones if France or Switzerland ever changed their timezone, but what EAP stands for would be challenging to define.
2019-8-5 // August 5, 2019
5081-03-30 // March 30, 5081
-300-12-21 // December 21, 300 BC (proleptic Gregorian)
20-01-01 // January 1, 20 (NOT 1920, NOT 2020)
09:04:21 // 9:04:21 UTC
23:59:59.999999999 // 23:59:59 and 999999999 nanoseconds UTC
12:05:50.102/Z // 12:05:50 and 102 milliseconds UTC
4:00:00/Asia/Tokyo // 4:00:00 Tokyo time
17:41:03/-13.54/-172.36 // 17:41:03 Samoa time
9:00:00/L // 9:00:00 local 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/M/Los_Angeles // October 26, 1985, at 1:20:01 and 105 milliseconds, Los Angeles time
5192-11-01/03:00:00/48.86/2.36 // November 1st, 5192, at 3:00:00, at whatever is in the place of Paris at that time
1985-10-26/01:20:01.105+0700 // October 26, 1985, at 1:20:01 and 105 milliseconds, UTC+7:00
2000-01-14/10:22:00-0200 // January 14, 2000, at 10:22, UTC-2:00
ISO 8601 and RFC 3339 are fine for dates in the recent past, but they're not great as a general time format.
I think people are greatly misunderstanding why those standards exist. ISO 8601 is a building block for other standards (and itself builds upon other obsolete standards). If ISO 8601 is not a good fit for your application, you have no obligation to use it. But if you don't have a very good reason to do so, I'll just pick (a specific portion of) ISO 8601 and call it a day.
In general one problem with that request is that it’s possible to specify times that might not actually happen.
2030-03-24 01:30:00 Europe/London seems like a perfectly reasonable time stamp. But if the UK decides to move BST forwards by a week between now and 2030, that time won’t ever happen.
A problem with the future is that it is hard to predict.
Define whatever format you want, and there's always the possibility of a politician changing what the local time is.
Historically, the offset against UTC has changed by a few minutes, hours, or days. Is daylight savings used? When? It is not even certain that it is the same calendar that is used, or that there are 24 hours per day, when the day starts, which months there are, or which month is the first of the year.
If the time zone changes in the future, so that the specified local time no longer corresponds to the same time in UTC, then the time of the event has changed, even if the organizer still specifies 6 pm.
Changing the time of the event is the whole point: specifying the yet undetermined time that would be called 6pm according to the currently unknown timezone and DST offset on that day in the future, not a specific time that we don't know what will be called in the future.
> But it's possible that between now and 2030 they might adopt Central European (Summer) Time[1], or retry British Double Summer Time[2], or scrap daylight savings entirely.
Yes, and maybe East London secedes from the UK and uses a different time zone, so Europe/London doesn't specify the time zone you meant, anymore. This might not be likely for London, but if it's in the countryside of a less stable country and you just specified the time zone as the capital city, this might happen.
I prefer time formats that are actually implementable and don't depend on a large database that can change at any moment.
The current time formats depend on databases that can change at any time. I haven’t found one that is implementable and usable in the real world that does not depend on something that can be changed.
Countries change. Timezones change by decree. This is a pain but it’s the real world and our tools need to be able to deal with it. I don’t like it either, and no one cares, nor should they. Reality trumps preference.
The problem with ISO 8601 is that it isn't properly implementable. Anything except Zulu time is basically broken.
The tz database is updated on average every two months, and that doesn't happen without reason. Countries keep changing their timezones, and a rather high-profile one is the European Union's plan to get rid of DST over the next few years. This is already happening in Greenland this year. Some Muslim-majority countries also like to make their DST depend on Ramadan - which falls on a different and somewhat unpredictable date every year.
Like it or not, if your code uses future dates and does not rely on "Europe/London"-style timezones, you will be slowly corrupting your data.
How so? 2030-07-01T18:00:00+01:00 is a well-defined point in time, is it not? It may or may not be local time in London, but it's unambiguous.
July 1st 2030, at 6pm, Europe/London is not. What's broken is the idea that you can somehow standardize "local time at a particular place" in a way that magically survives any arbitrary policy change.
> Some Muslim-majority countries also like to make their DST depend on Ramadan - which falls on a different and somewhat unpredictable date every year.
Thus proving that what you want does not exist and cannot exist.
> How so? 2030-07-01T18:00:00+01:00 is a well-defined point in time, is it not? It may or may not be local time in London, but it's unambiguous.
It's a redundant way of writing 2030-07-01T17:00:00Z which only serves to cause confusion (it misleadingly looks like a local time, but it isn't). TAI or equivalent are useful; symbolic timezones are useful; numeric time offsets are useless and there's no benefit from having them be part of the standard.
> Thus proving that what you want does not exist and cannot exist.
Of course it does; 2030-07-01T18:00 Africa/Casablanca is a real time that humans will have no trouble attending a meeting at, and nor will computers as long as they've been keeping their zone file up to date. All we need is a standard for storing and interchanging it on computers.
It's not though, the rarer the edge cases are the more they trip you up. Like how UTF-16 is worse than UTF-8 because it's easier to be fooled into thinking it's a a fixed-width encoding, but it isn't.
> No one thinks that +01:00 will magically turn into +02:00
Not consciously. But they think it's always going to match the time on the clock in their office / on their town hall / on their phone. No-one deliberately writes a time in the time offset corresponding to their local winter time for an event that will happen in their local summer time (or vice versa).
> want a timestamp that's intuitive.
I don't know about "intuitive", but they want to write times in their local civil time.
> How so? 2030-07-01T18:00:00+01:00 is a well-defined point in time, is it not? It may or may not be local time in London, but it's unambiguous.
Being unambiguous isn't helpful if it is wrong. It is a very common desire to want to set a meeting based on the local time of a destination. The only future-proof way to store such a time, is to remember the destination and the desired local time. This is the only way the proper moment can be calculated and kept in sync with reality.
The unfortunate fact is, the local time could be altered by decree, in any number of ways, in the interim timespan between setting a reminder, and when it happens.
Even that isn't guaranteed to work, because different sets of people in the same place might have different time zones based on political affiliation. That's rare, but it has happened so it certainly could happen again.
> It may or may not be local time in London, but it's unambiguous.
True, but unfortunately humans only care about local time. Setting a meeting for "6PM London time" is how pretty much the entire world operates. If your app can't deal with that, your app is doing it wrong. The world doesn't care that it isn't "well-defined", as developers we just have to deal with it.
> Thus proving that what you want does not exist and cannot exist.
But it does exist, and many calendar apps operate exactly like that. It just requires them to update their timezone database every few months - which in many cases already happens automatically as part of OS updates.
"2030-07-01T18:00:00+01:00" conveys no more information than "2030-07-01T17:00:00Z". The UTC offset is meaningless because it is impossible to get a timezone from it, so it cannot be fixed in the future. It essentially screams "we tried to do local time and failed".
> I don't think it's unreasonable to want to be able to specify a meeting in London, on July 1st 2030, at 6pm local time - no matter what happens to UK timezones between now and then.
What's unreasonable is wanting this to be one piece of information.
Location and time are distinct concepts that need to be split up.
A timezone is not a location. Timezones are just a subjective shorthand convenience for display purposes, not actually tracking time. The reason the abstraction sucks is because the idea sucks.
> The reason the abstraction sucks is because the idea sucks.
Got it in one. Relativity, universal time, the human circadian rhythm...
To quote my all time favourite HN comment quoting Plautus (presumably taken from R.R.J. Rohr's 1970 Sundials: history, theory, practice):
> The gods confound the man who first found out
how to distinguish hours! Confound him, too,
who in this place set up a sundial,
to cut and hack my days so wretchedly
into small portions! When I was a boy,
my belly was my sundial — one surer,
truer, and more exact than any of them.
This dial told me when ’twas proper time
to go to dinner, when I had aught to eat;
But nowadays, why even when I have,
I can’t fall-to unless the sun gives leave.
The town’s so full of these confounded dials
the greatest part of the inhabitants,
shrunk up with hunger, crawl along the street.
— Plautus (c.254-184 BC)
"Whatever time 6pm is where we are" is a reasonable concept to want to express. You can't guarantee ahead of time when it will be, but it matters to people.
When I worked on a system that provided schedules for appointments, it was quite difficult to furnish a link that put this on someone's calendar reliably, and to set up reminders that went out every third Monday of the month at 9am to remind people to go to their clinic appt at 11am. People are equally annoyed at 8am or 10am reminders in such a case, so you can't tie it to a specific time, and daylight savings time gets changed from time to time, and various locations have "9am" at different times. We didn't even get into the weeds of whether someone who lives in Phenix City, AL should get notices in Central or Eastern (it's Eastern for most people, except if they work for the government or are going to school... unless it's a private school, which might still be on Eastern...).
Telling someone they can get their notice at any time they want as long as it's specified in UTC year round just doesn't solve the problem they have.
Oops you're right. I forgot to also say that the date is not the time.
The date can be stored together with the time as a timestamp, but all timestamps need to be in UTC. Getting the user's locale and applying their timezone is done on the client side. What matters to people stays on the client side.
The client might be a desktop app, a smartphone, a web browser (maybe in a public library, where they don't control the locale...), or just an SMS receiver. The only reliable place to apply these things is on the server, where you can look up the location of the appointment or event, and the preferences of the user, and apply whatever skew is appropriate.
If they really meant in London, and not just "London time", then yes. The lat/long can be used by the client side as needed to determine the user's locale, if the meeting is actually in London anymore, or indeed if London itself even exists anymore!
It’s LocalDateTime AND geographic coordinates, not a name of a timezone. Maybe we need an ISO standard for universally accepted location/event identifiers or an URI schema, eg:
Yes the basic problem here is that people for some reason think that a time zone is a property of a time when in fact a time zone is a property of a place. It’s actually a mutable property of a place, to make things more complex.
Well that’s more a case of there being more than one authority who claims to be the source of truth for answering the question ‘what is the time zone offset in that location at this point in time’…
International disputes make it difficult to answer a lot of questions about specific locations without making choices about which authorities you’re willing to respect.
Not instead, but in addition to. Maybe 3rd element of the vector must be the moment when the identifier was created, so that knowing history of the location it could be possible to adjust it to the current coordinates.
>I find it weird that there's no way to specify a future date/time with respect to a specific timezone, e.g. Europe/London.
It makes sense to me that it is not provided as it is something fundamentally different. ISO 8601 / RFC 3339 are just textual representations of specific[*] time moment (or interval), that could be easily converted to different definitions of time moments.
OTOH, specifications like '2030-07-01 18:00 local time in London' are not a definition of a specific time moment, the are really a description of a condition, and we cannot resolve it to a specific time moment before it happens.
So these are two fundamentally different concepts that does not make sense to put into one category.
It's in ISO 8601. See the "Z"? that means "Zulu" or "+0". You can specify any offset. This is standardized and immutable. What offset is correct, however, can change due to local madness, and no standard could possibly keep up.
But I do love the `date` utility, which allows alphanumeric time zone abbreviations pretty well.
The suggestion above is to have the zone in the timestamp. ISO-8601 and RFC-3339 put the offset in the timestamp.
Zone and offset are different concepts: the up-thread comment's poster's example of Europe/London is one zone, that currently has two offsets, depending on time of year.
The up-thread comment includes a very practical example that any app dealing with something like an "appointment" would have to reckon with.
The meaning of a wall clock time is based on the legal jurisdiction of where the clock is located. It is the local law which sets the daylight savings time rules. These are commonly written as TZ / tzdata / IANA names, as in “Europe/London” from the person to whom I replied.
Offsets are just fine for timestamps, and other historical data. And much simpler than having to maintain history of TZ data, and trusting that all your collaborators are using the same TZ db.
It is only scheduling future events where they fall down. Calendars and scheduling are demanding applications.
I personally find UTC offsets pretty useful for (free-form) meeting scheduling, i.e. "see you at 15:00 (UTC+2)" beats "see you at 15:00 (CET)". It makes quick mental math to figure out what that is in my current timezone so much easier.
Otherwise, I'm also always left wondering whether they really meant CET or actually CEST, calculating what the current offset of CET is, double-checking whether there's some other CET that I might be confusing things with (China Eastern Standard Time?) etc.
You are assuming a small sensible change. The actuall changes could easily make that time to already have occured, and to occur multiple times in the future for example.
I have never thought about it before, but are timezone names like 'Europe/London' designed to not be sensitive to political changes and not have to change?
It could have been Country/City or Region/Country but it's Continent/City instead.
Continents or regions of the world don't change fast or due to politics (not often) and cities aren't renamed or disappear that often, so this scheme is probably a lot more stable than any that uses political entities. (Think about countries that split or rename or become occupied, the locations of cities like Sevastopol (occupation), or Juba (Sudan/South Sudan split) or Jerusalem (every controversy).)
You are either joking or you really think a RFC to cover such changes is possible? If so, do you have any examples in mind? Cities that stop existing is not a new problem.
Not necessarily the scheduled event may be in some other city in a different time zone that wants this timezone for the convenience of scheduling attendees from across the world.
In which case a new calendar appointment will be circulated to the survivors with location and details. This mechanism already exists and is surely adequate.
The point is to have some means, some facility, to schedule things 100% correctly in advance. If there literally is no possible method then that's a pretty surprising aspect of computer systems circa 2023.
Such an absolute perspective on the utility of computer science isn’t very pragmatic. Computers have the power to interact with the real world, and play a major part in billions of lives every day.
Of course, then you get into the problem of whether you want to store that by time zone, or by actual physical location. If it's the latter, you might have to deal with the time zone that covers that location changing at some point between now and then, like when Kazakhstan merged what were previously two separate time zones into one.
Yes, a suffix like `S`/`W` (for Summer/Winter) or `+`/`-` in place of Z would help with disambiguation.
But you still need to handle the case where the local time is skipped. You could pick the timestamp during which the skip happens, but that'd lead to an offset that can contain fractional seconds, which almost no datetime library supports.
That works until a country decides to hop across the international date line the day after they switch from DST to normal time, and the timestamp occurs three times ;)
My personal pet peeve with ISO 8601 is that the time zone can only be specified to the minute. There are common time offsets in use which require seconds resolution - for example GPS time which is currently 18 seconds off from UTC.
If the Earth's rotation speeds up or slows down, would you like the "6pm local time" to be 6pm plus the leap seconds that come in between now and 2030? (We don't know how many there will be yet.)
Most of the time RFC is the way to go as ISO specs are not available for free and many open source implementation are actually not fully open source compliant because based on drafts. It's also a really big effort for open source devs.
Also, if you are working on anything dealing with date in the future, you nearly always want to store wall clock time + location. Sadly, there is no standard for that.
In Europe and USA the timezones are quite stable, so we might not be confronted to this, but in many places timzones change quite often, and storing an offset is not stable. Having "june 5 2026, 13h30 wall clock, paris" is what most people will mean, and it might be UTC+2 or UTC+1 depending if EU finally decide on what to do with DST.
And finally, if you write an API with times in the past, just use POSIX timestamps in seconds, ms, us or ns.
> Also, if you are working on anything dealing with date in the future, you nearly always want to store wall clock time + location. Sadly, there is no standard for that.
iCalendar is an RFC standard for this. [1] Note that some times have two representations and some times are not representable in this format when there's a time change due to DST.
iCal also does not contemplate a location being reassigned to a different time zone, an issue discussed elsewhere in this thread.
Of course, properly formatted iCal files also include data for all of the referenced timezones. Which makes it cumbersome if you just wanted to output a single datetime.
There is a draft standard called IXDTF that extends RFC 3339 to include the IANA timezone names in square brackets: 2026-06-05T13:30+0200[Europe/Paris]
The IANA timezone database uses place names (mostly city names) for that reason. "Europe/Paris" in that example I gave is very not "Central European Summer Time" (or "CEST"), Paris' current timezone name. The IANA's timezone database tracks key cities and especially ones with historically unique timezones or that have shifted between timezones.
It certainly doesn't list all places, but it lists most of the key ones that have carried weight on timezones, and is about the best database a lot of internet nerds have managed to accumulate of a lot of the complexity of current (and historic) timezones by roughly place name.
Call me lazy, but tryping the latter took me 20 times longer. I totally would use it for internal state, but I would not store it like that or expose that to users ever.
But you're talking about JSON, not a concise string that is exposed to users, and not a data format optimized for size. If you want more than a basic type you give it structure - and durations are not trivial types nor common enough to deserve their own representation.
Durations optimized for storage without ambiguity would be the tuple (u64, u32, u8) where the first value is seconds, second value is nanoseconds (if precision is needed) and final value is epoch.
Durations displayed to a user wouldn't ever be stored so the point is kind of moot.
Optimizing for "time it takes someone to write it once" is kind of dumb since it happens once while reading it happens often, and parsing even more likely.
It just depends on how you are using the JSON and where it fits in an application. If I'm using a static language, it is common for me to have a TimeSpan (or similar) type and standard rules for how it can be serialized (e.g. toString, toJson, etc). In this scenario, I don't care how it is represented in JSON, I just want convenient (de)serialization.
With your example, I would need to create custom parsing logic, and handle a dynamic number of JSON fields. But if a TimeSpan class had JSON deserialization built in based on the ISO8601 format, then I wouldn't need to do anything special. That's the benefit of using the standards. Same if I wanted to convert the JSON stringified format into a postgres time span there isn't any special parsing logic I need to do.
Yes, it's just a string in JSON, so it's not semantically special. But other languages that have a TimeSpan type could take advantage of the standard serialized format.
Here is an example of what it could look like in F#, no special logic for deserializing into a custom type:
type MyEvent = {
myDuration: TimeSpan;
createdAt: DateTimeOffset;
eventId: string;
}
let rawJson =
"""
{
"myDuration":"P15DT5H0M20S",
"createdAt": "2023-08-24T20:30:00Z",
"eventId": "e_1234"
}
"""
let myEvent = JsonSerializer.Deserialize<MyEvent>(json = rawJson)
I see your point, but I guess I don't see the difference between it being structured as a string with a second deserialization step after JSON deserialization. I see the convenience of a standard way to deserialize the time stamp.
But either way you need multiple pieces of data for the duration to be correct and useful. Without the created-at time in your example the duration will be invalid in the presence of leap years/seconds.
If you want to unambiguously encode a duration of time, it needs to be in the smallest unambiguous unit that is meaningful (usually seconds/nano seconds). That will allow your duration to be correctly used without any additional logic/metadata packed along with it.
It's "funny" how both RFC 3339 and ISO 8601 standards include a huge number of redundant DT formats with often overlapping purposes, yet "2023-09-01 15:30:59", which is by far most used DT format (because it's fucking obvious!) across all systems is included in neither.
Also, both standards are very unclear on how to represent DTs BC, and how to represent DTs after 9999-12-31 (or before -9999-01-01), and most commonly used libraries often just cannot handle them at all. And even when they can, the behavior of 00-01-01 is basically undefined (may I remind you, that Gregorian calendar is stupid, and the next year after 1 BC is 1 CE). In short, basically no software except for specialized astronomical software handles anything beyond near-future unix-time, even though for most purposes (like, uniformly representing DOB/DOD of Emperor Augustus) it's really not rocket science (we are really ok with just storing strings) and just needs to be clearly defined in some standard!
> It's "funny" how both RFC 3339 and ISO 8601 standards include a huge number of redundant DT formats with often overlapping purposes, yet "2023-09-01 15:30:59", [...] included in neither.
ISO 8601 does allow for that format given a mutual agreement. The "mutual agreement" sounds serious but means nothing more than a simple qualifier like "ISO 8601 where `T` can be replaced with a space" (RFC 3339 also does this in a much wordy way). I don't think how this makes things unclear, esepcially when people generally are unaware of ISO 8601 anyway.
> [...] which is by far most used DT format (because it's fucking obvious!) across all systems [...]
I'm not even sure that this is the most used date-time format. The most spoken language is Chinese, for which native separators like 2023年9月1日 are common.
> Also, both standards are very unclear on how to represent DTs BC, and how to represent DTs after 9999-12-31 (or before -9999-01-01), and most commonly used libraries often just cannot handle them at all.
Again ISO 8601 allows for year numbers before 1582 (yes, they are not allowed by default) or after 9999 given a mutual agreement. Such numbers should be prefixed by a single sign character if it can't fit within 4 digits. They are generally not supported because we can't really do anything meaningful with that past or future date, but nevertheless I have seen enough libraries that do parse them (particularly common when they are implemented independently from C <time.h>).
> And even when they can, the behavior of 00-01-01 is basically undefined (may I remind you, that Gregorian calendar is stupid, and the next year after 1 BC is 1 CE).
It is defined as January 1, 1 BCE. ISO 8601 clearly states that its year number is for the proleptic Gregorian calendar, so it infinitely extrapolates back to the negative infinity.
I was originally about to answer the counterevidence... But wow, you are actually correct! I don't have a copy for ISO 8601-1:2019, but 8601-1:2016 [1] has the following note in the section 4.3.2 Complete representations:
> 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.
I thought this allows a replacement of [T] with a space, but it doesn't state so! It just means that the time designator can be omitted, e.g. 2023-09-0117:12:30 instead of 2023-09-01T17:12:30. It does look very strange (especially when used with extended formats) and I'm not sure if it was actually intended or not as there is no accompanying example, but nevertheless the 2016 spec doesn't allow a space. Oops.
EDIT: It indeed seems that ISO 8601-1:2019 no longer has this note. I now agree that this is a bad move. https://stackoverflow.com/a/9532375
[1] Specifically the Draft International Standard that was once available from loc.gov.
"8601-1:2016" is not a thing. As you note there was a draft released in 2016 but was changed quite significantly before publication in 2019. That's why the LoC link isn't all that useful for settling disputes.
You are correct that previous editions allowed omission of the 'T' in DateTime expressions. ISO 8601:2004 (the most recent version before ISO 8601-1:2019) states in § 4.3.2:
> NOTE 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.
This was removed with the 2019 version. However there is another section in the latest version which some people get caught out by. ISO 8601-1:2019 § 5.3.5 states:
> In time-only expressions, UTC of day expressions and time of day with time shift expressions, the
time designator [“T”] may be omitted in the representations defined in 5.3 only when there is no risk
of confusion.
This only refers to Time expressions (not DateTime) and says that both "T16:40" and "16:40" are valid time representations.
> It's "funny" how both RFC 3339 and ISO 8601 standards include a huge number of redundant DT formats with often overlapping purposes, yet "2023-09-01 15:30:59", which is by far most used DT format (because it's fucking obvious!) across all systems is included in neither.
It's much readable too. I recently started ignoring both standards in favor of the nicer space-separated format after almost two decades of sticking with the former. I get why they needed a non-whitespace character but they could have at least used an underscore or a dot.
And I have no idea why they sacrificed the universality of the format by limiting the year segment to only four digits. It's a string!
Yes, that's what I mean by "obvious". And I mean to say that it's REALLY important IMO. The point of having a standard is to abandon ALL other ways of representing a DT (or at least go as far as possible in that direction). RFC 3339 and ISO 8601 make that basically impossible. Most of your coworkers (let alone non-technical business people) don't give a damn (or even know anything, really) about standards and will represent DTs differently in different places. I can force them to use 2023-09-20 instead of 2023/09/20, and MAYBE even instead of mind-boggling USA-ian format of 09/20/2023, but I sure as hell cannot force them to use "2023-09-20T20:30:59" instead of "2023-09-20 20:30:59". Because it's less readable, and it's not arguable.
> And I have no idea why they sacrificed the universality of the format by limiting the year segment to only four digits
No, there are reasons. People often represent year with 2 digits, so forcing you to use 4 digits is basically intended to make representing 20 CE unambiguous as 0020-01-01 (as opposed to 20-01-01). But, I mean, it's a problem to be mindful of when making a standard, not an insurmountable obstacle. A real standard to end other formats once and for all just needs to make sure to take care of all corner-cases. The truth is RFC 3339 and ISO 8601 are just shitty standards.
(Edit: Also, just in case, note that it is possible to use 5 or more digits in ISO 8601. But the standard says that the parties must agree beforehand on that. That's what I mean by "unclear". I cannot just say that you MUST represent DT in ISO-XXXX format, it's not specific enough. In the end we must to agree on how our systems will behave when receiving this or that value anyway, so it makes having an external "standard" pretty pointless, since the standard is pretty clear about very obvious situations, and very hand-wavy in all actually non-trivial situations.)
Ambiguously. I've seen a lot of different cutoffs, including 1930, 1950, 1970 and 1980. And those cutoffs don't actually exist in the human conversation: I would guess the century, and if something sounds off, I'll ask the exact year number and get corrected or verified. Computers can't do that (or at least, should only do in the frontend).
> I cannot just say that you MUST represent DT in ISO-XXXX format, it's not specific enough.
Laypersons have no idea what the heck is ISO 8601 anyway. I'd just say: use the format "yyyy-mm-dd hh:mm:ss", padded with enough zeros. Then I'll parse it as if ISO 8601 date and time format with the `T` omission is allowed (because it essentially is). Done. I wouldn't ever try to figure out the meaning of, say, `23-09-01 12:34:56` because they are ambiguous and should have been discouraged after all (or more practically, allow a free-form format but give the guessed normalized date and time in ISO 8601 immediately so that it can be checked).
> Laypersons have no idea what the heck is ISO 8601 anyway
Damn, that's a great point for sure. Then what's the point of having a standard if "nobody has any idea" what it is and and you are supposed to define all the details of the format with all corner-cases in a private conversation anyway?!
That's right, there's none. The whole point of having a standard is that I can say that the value is "ISO 3166-1 alpha-2" country code, and you know that you MUST recognize all officially assigned values (or you don't really implement the protocol) AND that you'll never receive, say YY, unless ISO assigns it a value (or it would mean I violate the protocol). Now, just to be clear: this standard is also not as well-defined, as I'd like it to be — since some values can be user-assigned, and in effect 2 different implementations of "ISO 3166-1 alpha-2" can be incompatible. And I don't really see the point of referring to a changing standard without specifying a version. But it's as good as it gets here, and is totally enough for 99% of cases where you'd need country codes.
ISO 8601 is way worse, since it doesn't unambiguously cover even relatively basic use-cases of how people use dates, and in effect we have lots of "somewhat ISO 8601" protocol implementations that are incompatible, and it cannot be clearly communicated what is the actual scope of your implementation by linking a sub-standard, and in the end you have to "just say": use the format "yyyy-mm-dd hh:mm:ss", padded with enough (what does "enough" mean, by the way? no clue) zeros. I.e., you have to not to refer to any standard at all. And given ISO 8601 is also clumsy as hell, most people prefer to use home-baked format anyway.
> Then what's the point of having a standard if "nobody has any idea" what it is and and you are supposed to define all the details of the format with all corner-cases in a private conversation anyway?!
Because they are often building blocks for other standards, not necessarily to be used directly.
For example there is an ISO standard called ISO/IEC 5218, "codes for the representation of human sexes", and it is simply 1 for male, 2 for female, 0 for not known and 9 for not applicable. So should the male called the sex 1? Not at all. It exists because many existing databases used such values for sexes (or genders, whatever they are). If you are not benefitting from using ISO/IEC 5218 and there is no associated legal requirement then you have no obligation to use it. Same for ISO 8601 and pretty much every standard.
If you want to create a forgiving enough date and time format that aims to be adopted as much as possible, go ahead, but ISO 8601 doesn't have to do that.
> [...] in the end you have to "just say": use the format "yyyy-mm-dd hh:mm:ss", padded with enough (what does "enough" mean, by the way? no clue) zeros.
You are correctly guessed that this description is not for everyone :-) (For example, I haven't said that it uses the Gregorian calendar.) ISO 8601 does cover that. But not everyone has to fully understand ISO 8601 to write an ISO 8601 date and time---we can just tell a (typically small) difference between the "common" format and ISO 8601.
> [...] in effect we have lots of "somewhat ISO 8601" protocol implementations that are incompatible, and it cannot be clearly communicated what is the actual scope of your implementation by linking a sub-standard, [...]
"ISO 8601 date and time format with the `T` omission is allowed" is a concise and complete description and not "somewhat ISO 8601". The standard explicitly says that parties can choose to pick this extension, meaning that the standard itself works well whether the extension is used or not and other defined extensions won't collide with it. This is different from something like "the format yyyy-mm-dd" for the reasons I've detailed above; it is okay as an explainer, but not enough as a specification.
I do think though that ISO 8601 will benefit from explicit labels for those extensions.
Look… How often are you referred to ISO/IEC 5218 standard, honestly? Me — it very well might be that you're my first. But it's nice it's there. If it wasn't, I wouldn't be very sad, because M/F/None was probably enough for me so far (and is actually way more permissive than most of actual protocols where I had to specify human sex, which usually allow just M/F).
ISO 8601 on the other hand… First off, datetimes are everywhere, and are used constantly. Second, datetimes are far less trivial, and it actually requires some good amount of thinking to come up with a good representation. It is even more complicated to communicate that specification in all of the details. So, forget about whether ISO 8601 exists or not — the fact is, that I need a datetime standard. I need it every day, many times a day. Everyone needs it. Everyone comes up with his own shitty standard at least a couple of times during his life. Nobody can really communicate his own shitty standard unambiguously, covering even most popular corner cases, because only very rare people actually thought about the problem half as much, as it has to be thinked about to come up with something remotely good. And since pretty much everyone even acquainted with a notion of "standard" regards ISO as the "standards organization" we end up referring each other to ISO 8601 often enough that I know what one is talking about without actually googling the code. Technical people almost consider it a virtue of not coming up with their own standard, if there already is a usable one (and for a good reason). Long way short: ISO 8601 is important. Way more important than ISO/IEC 5218 or some meme tea-making manual. And it doesn't live up to what is (and, my point — should be) expected of it.
The range of what HTML allows is far more used in practice, in my experience. Which is kinda sad, because "HTML date format" isn't really format I should be referring to, ever, it's ambiguous, it's not commonly recognized, and it doesn't even account for a number of very important use cases ISO 8601 accounts for (date ranges, for one).
Now, I'm not sure which part of your post would I quote, but basically you are missing my point in the whole second half of your post. You are spending a lot of time talking about "T vs space" (which, unfortunately, might require that much time talking about and more), while this is really the trivial thing, everyone would get on the go, since it's so commonly used. So, because it's so intuitive, it's the part of the problem that begs about being standardized the least. What really begs for a standard are all these less obvious situations: 2-digit years, years before 1582, years BC, years after 9999 — which, unfortunately, are really not that uncommon. Honestly, they are common, even.
And while — as I said from the very beginning — ISO 8601 does make some half-assed attempts to address all these issues, in practice it doesn't communicate any of possible scopes of values clearly enough. In effect, there are lots of applications, that pretend that they "parse ISO 8601 datetimes", yet you'll find out that, say, Python standard library just doesn't handle negative dates at all. Which is ok (I mean, bad, but understandable), but the problem is that you really have to think about it yourself to even find it out. And the big value proposition of having a standard is exactly that you don't have to think about all the details, you just rely on the fact that Wikipedia (a big, reputable project) claims that it uses standard X for the datetimes, and Python (a big, reputable project) claims that it's standard library function can parse standard X datetimes, and you just assume that someone did all the thinking for you already and they are compatible. And ideally there should be standard Y such that it makes it trivial to refer to X = Y-1 and X = Y-2 and see that they are, in fact, incompatible.
So in practice ISO 8601 just doesn't do what it should.
> I sure as hell cannot force them to use "2023-09-20T20:30:59" instead of "2023-09-20 20:30:59". Because it's less readable, and it's not arguable.
RFC 3339 does allow the format "2023-09-20 20:30:59Z", which is more readable, although it requires either the "Z" specifier or an offset like "+00:00" at the end.
From the RFC:
> 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.
You can also verify this with the validator on the website OP linked.
6 digit years seem like a solution to a problem that will never be for the sake of looking forward thinking. There's absolutely no way current technology or social norms will last 8000 years.
Yeah, but don't forget we use computers for things that don't involve today only.
Let's say you run a climate calculation for long enough for example. Now you could just say "fuck dates" if they error — but wouldn't it be kinda nice if they didn't?
If you want to project something beyond 9999-12-31, you can do that with custom timestamps, e.g. by specifying the year as a float. There's no need to convert that back to a timezone or sync it to UTC. The maximum difference of 1 day would be 0.00003% in 10K and decreasing, a level of accuracy no simulation can ever achieve.
Would you really need a full date and time stamp for doing that? If you're talking about projections 10,000 years in the future do you care if it's mid-afternoon on a tuesday?
> ISO 8601 uses a hyphen character (in Unicode, U+2010 HYPHEN "‐") and minus character (in Unicode, U+2212 MINUS "−").
When using character sets which don't have these characters a hyphen-minus character (in Unicode, U+2D HYPHEN-MINUS "-") should be used instead.
This is incorrect. What ISO 8601 actually specifies is that, if the target character set is based on ISO/IEC 646 (which definitely includes Unicode), then a hyphen-minus character should be used for both cases. There is a slight ambiguity here (e.g. what if some charset contains most but not all characters in 646?) but in the case of Unicode the interpretation is clear. I believe this is a roundabout way to specify the canonical mapping for 646 and guarantee the compatibility with other charsets based on 646.
The relevant paragraph from the standard is in ISO 8601-1:2019 §3.2.1:
> All characters used in date and time expressions and representations are part of the ISO/IEC 646
repertoire, except for “hyphen”, “minus” and “plus-minus”. In an environment where use is made
of a character repertoire based on ISO/IEC 646, “hyphen” and “minus” should be both mapped onto
“hyphen-minus”.
And as you correctly state, Unicode is based on ISO 8859 which is based on ISO 646. So it would seem the intention really is to use U+2D hyphen-minus when Unicode is the character set.
It bothers me on a regular basis that there is no RFC 3339 acceptable way to include date and time in a file name in Windows as a colon is a special character. I also wish you could use hyphens in the date while ignoring the colons and still be ISO 8601 compliant, for example 20230831T1510-0500 is compliant and can be used in a filename, while 2023-08-31T1510-0500 (and similar variants) is not. As an aside the "Get-Date" function in PowerShell doesn't understand the first timestamp without the hyphens and colon.
I hadn't realised that there was a problem with Windows. MacOS has a different problem with a colon in a file name. For two of the three most popular operating systems to have this problem does show a distinct lack of thought.
I'd prefer to use space (or underscore) instead of T to separate the date and time parts, but generally stick with T to avoid problems with anything that can only handle ISO 8601 (and to be consistent).
Judging by the time it takes to completely migrate away from old technologies, I wouldn't be surprised if we will be emulating x86 on our quantum computers in the year 100k.
A self-contained full implementation of ISO 8601 is of dubious value anyway.
Whether time is used for a private application or for a standard, the important part is the agreement on what information is being conveyed and in what format. Receiving just the week of the year when you were expecting a time range is not useful.
Likewise, having some sort of official support for "20" as identifying the century (say via a Century type) is a lot of code to carry around and maintain - especially before there's a business need to represent centuries. You tend to need full date time instants, then maybe dates and times independently, then maybe durations - with only a few applications tending to need things like ranges.
Yeah, this means that when you want to use ranges and choose ISO 8601 as your format, you may not find readily-available, off-the-shelf parsers.
Both Golang (official time package) and Rust (Chrono) have built in tools for dealing with RFC 3339 but not for RFC 8601. IIRC I read about issues with ambiguity in RFC 8601 not present in RFC 3339, and again IIRC Python had issues round-tripping dates because of this.
Interesting. This is the first time I'm even hearing of RFC 3339. ISO 8601 is just taken for granted everywhere... languages, tools and services (databases, etc).
Admittedly I've not worked with Golang or Rust, and my Python has been limited to scripting more than developing.
The ISO8601 standard is behind a paywall, and consequently many of the "ISO8601" functions in programming languages and libraries don't actually support anything but the subset that is also RFC 3339.
ISO 8601 has become popular enough that many systems take it as a shorthand for yyyy-mm-ddTHH:ii:ss.*, and perhaps the date only yyyy-mm-dd, without caring much about the other parts of the specifications.
It was a long time ago but I have memories of Apple's Objective C frameworks not supporting huge swaths of it. And it's worse for private systems that can just tell the clients to keep it inside the generic formats.
In that sense, ISO 8601 or RFC 3339 are virtually the same for many systems/companies.
Possibly; this assumes that our current calendar's epoch holds, that humanity is still around, that computing systems are still around, and legacy software from 8,000 years past is still kicking people in the butt.
Given that electronic computing has only existed since approximately the 1930s, it's probably premature to worry about what will happen 8,000 years from now.
1) There's nothing special about 6 digit years. You can also use 5, or 7 digit years, or whatever the two parties can agree to before communication starts.
Part 2 of the standard gives examples of years with 10 digits.
> 2) ISO 8601 is prolific. Is RFC 3339 well used/adopted in any system?
ISO 8601 was first published in 1988. RFC 3339, while ostensibly dated July 2002, codifies practices that date back to Usenet and e-mail (RFC 822: August 1982), and perhaps to the date utility (which existed in Version 1 AT&T UNIX).
Nah, email and classic Unix use entirely unrelated date formats. The RFC 822 format looks like "Thu, 31 Aug 2023 20:53:11". Unix / ctime(3) uses "Thu Aug 31 20:56:52 2023".
Ah, I see that listed as a valid ISO 8601 format in the table, but not in the visualization, so I missed it. Also I can't say I've ever seen the basic format in the wild, is there anywhere it's used regularly?
When the timestamp gets slammed into a file name, as the colon is reserved on Windows and MacOS. Also, when space matters, as it's very slightly shorter.
One part of RFC 3339 I dislike is `Z` vs `+00:00` vs `-00:00`
> Unknown Local Offset Convention
> If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00".
> This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time.
`Z` should have been used to represent the unknown local time case, and `-00:00` shouldn't exist, while `+00:00` could be used if UTC is the preferred reference point.
In practice `Z` is already used for the "no preferred local time" case very often.
I thought Z was a reference to (NATO) Military time zones [1], where Zulu Time Zone is equivalent to UTC+00:00, but uses fewer characters.
iCal uses the Z to indicate times intentionally in UTC as well, as opposed to times without a time zone indicator (use unknown local time), or times with an explicity time zone indicator.
Using Z to indicate 'please use whatever local time seems appropriate' seems like poor practice, even if it's a common one.
In my experience "this timestamp is UTC, show it to the user in whatever timezone they might be in" is the most common case for times in an API/file format, so giving it the Z shorthand makes sense to me.
While when using an explicit time offset, `+00:00` doesn't appear particularly special or more common than other offsets, so I don't think a shorthand for this case is useful.
Other than instants in time and durations, other expressions of time information tend to be a bit more "wibbly wobbly, timey wimey". For instance, I might specify the week of the year without any more precision.
Another example is that a date can't be converted to a range of instants in times (the first and last second within the day) without knowledge of where it is observed. Games for instance will measure this at some business-decided timezone (say UTC or the timezone of their first server), because having events time out at different times for different people is much more complex.
So when representing an instant in time, a UTC shortcut is easier - if people agree that times are shared with a Z offset, then you simplify parsing. However. there are reasons people would also want a fully specified point in time that preserves a timezone offset as well.
I assume they chose -00:00 because ISO 8601 forbids it, so there isn't an issue of a compliant ISO 8601 stamp having a different meaning under the RFC.
Does anything in practice care about + vs. - 00:00, though? Seems kind of unlikely to be widespread. Among other reasons because people don't know about it. I think if anything I'd have just left the concept out entirely.
Wow that is very surprising, I always thought -00:00 was just a synonym for +00:00. That seems almost intentionally misleading, why not Z like you say or just +? or something?
Thank you for this comment. I saw the `-00:00` in the RFC 3339 bubble, and was confused as to why it wasn't mutually agreed upon. Your comment makes clear the the `-` has special meaning that I hadn't picked up on.
In the general case, durations can be non-intuitive or ambiguous when applied across DST changeovers or leap seconds, or when they include a month count.
It’s a reason why generic durations aren’t often used. Usually you restrict it to be a simple count of seconds or days or whatever is appropriate for the use case, and then you don’t need any special notation, because it’s just a numerical quantity that you store/transmit like any other numerical quantity, its unit being implicit in the schema.
ISO 8601 supports all sorts of corner cases, apparently. But it costs money to get the full standard, unlike RFCs. Someone bought a copy and was answering questions few years ago:
In Britain, standards can sometimes be obtained for free via your library subscription (which would be orders of magnitude cheaper than the standards are directly, due to government subsidies for libraries).
Representing ranges/intervals ("1st-5th of September 2023") and periods of time ("Four days and two hours")
It can represent a month without a day ("April 2024"), and a year without a month ("2024").
In some countries week numbers are used for various purposes ("School starts in week 33 of 2024", "Recycling will be collected in odd-numbered weeks.").
ISO 8601 also has notations for all sort of stuff the RFC doesn’t need, like uncertain and approximate dates (for libraries or museums perhaps), as well as repeating events, durations, intervals, and such (some of that part is a riff on iCal, or so I’ve heard); most of it is in 8601-2 (which is a thing since the 2019 revision) but some parts are in -1.
JS date format pretty much lives at the intersection of them, afaict, so it should be the perfect choice for interoperability. Also, I gather it makes working with dates simpler if you can rely on a less variable format.
For the context, ECMAScript allows for any implementation-defined format besides from the mandatory ISO 8601 style format [1]. Browsers are noticably different here [2]; the equivalent `v8::internal::DateParser` class is no better.
the tables agree that microseconds are supported by both standards, but for some reason the Venn Diagram only displays 6-digit fractional seconds under ISO8601. This led me to do some head-scratching until I referenced the table, which seems a lot more comprehensive.
This is extremely cool and useful overall, but unfortunately the Venn Diagram seems to be slightly misleading.
hey, thanks for putting this out there and also for iterating on it! I will start using sending this to folks as a reference now that I know it's being maintained!
I don't think it's unreasonable to want to be able to specify a meeting in London, on July 1st 2030, at 6pm local time - no matter what happens to UK timezones between now and then.
The UK currently uses Z+00:00 from November to March, and daylight savings of Z+01:00 from April to October (roughly)[0]. But it's possible that between now and 2030 they might adopt Central European (Summer) Time[1], or retry British Double Summer Time[2], or scrap daylight savings entirely. Therefore, what happens to 6pm with respect to any given epoch might vary wildly between now and 2030.
But it would be nice to set a calendar event for "6pm London time", whatever London time happens to be when the event rolls around. But there's no standardised interoperable way to say "2030-07-01 18:00:00 Europe/London".
[0] https://en.wikipedia.org/wiki/British_Summer_Time
[1] https://en.wikipedia.org/wiki/Central_European_Time
[2] https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of...