Hacker News Reader

Comment by Karellen | Hacker News Reader

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".

[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...

View on HN

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.

[0] https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...

[1] https://tc39.es/proposal-temporal/docs/strings.html#iana-tim...

[2] https://tc39.es/proposal-temporal/docs/ambiguity.html#ambigu...

That's an excellent idea, and one which I should hope to implement in my calendaring software if it is accepted. Are you one of the authors?

No, I'm not affiliated with the authors, I just recalled seeing the extended syntax when I looked into Temporal's features a while back.

Maybe

` 2030-07-01T18:00:00[!Local] `

Where no offset and the !Local tell the app to use OOB defined location?

maybe ~ ?

    2030-07-01T18:00:00~BTC

    2030-07-01T18:00:00~CEST

    2030-07-01T18:00:00~Local

    2030-07-01T18:00:00~Europe/Warsaw

to signify it is not a constant point in time but timezone-at-the-time dependent.

The issue is, what do you mean?

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...

> The issue is, what do you mean?

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.

Perhaps I’m missing something?

I agree on not including the offset.

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.

> Perhaps I’m missing something?

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.

Except you don't even know if they in the future uses the same calendar.

We don't even know if the future can read or write in our commonly used alphabets.

Or maybe even time reverses course and runs backwards. See: PK Dick, Counter-Clock World, 1967.

tz name? Sounds super brittle to me when looking at history.

So what happens when a timezone name changes?

Say Manila timezone changes names to New Beijing timezone in the next 10 years (fictive example)?

If the timezone name changes, chances are I no longer want to meet at 6pm in London in 10 years' time without double-checking a few things.

Honestly, this applies to the entire rest of the thread too.

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.

tzdata does not remove timezone names.

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.

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.

And so, you want a probabilistic time estimate based on the likelihood of that passing?

Store the gps coordinates of the location for the meeting instead, along with the desired local time and local date.

But the local time would change according to GP's comment.

The top level comment said

> specify a meeting in London, on July 1st 2030, at 6pm local time - no matter what happens to UK timezones between now and then

GPS coordinates + local date and local time will preserve “a meeting in London, on July 1st 2030, at 6pm local time” in the desired way

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.

"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.

+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.

The point is that the local time would not change, even though the offset between UTC and local did change.

I see.

The problem is there is no difference between local time and "offset from UTC", right?

> 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.

As long as the invited people don't change nationality...

https://www.972mag.com/the-worlds-only-ethnic-time-zone/

If there's one thing I've learned about time keeping, it's that whenever you think you've got it all figured out, there's always one more corner case.

That seems to be in line with what GP wants.

I see. I misunderstood!

This limits your meetings to surface of earth, what if I want to meet with you on Mars?

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.

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.

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).

>there would be no automated way to associate those future-date-time values with the correct timezone

You could develop a way to specify a location and indicate that you mean 'local time' at that location.

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)

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.

There is actually a good read on this at https://www.ordnancesurvey.co.uk/blog/is-britain-on-the-move

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.

Especially assuming an increase in computing intelligence in that time.

The problem with geo coordinates is reverse mapping them back into political owners, so you can then determine current timezone policy.

There's 4 things at play here:

   - Coordinate location on the planet
   - Identifier for that location
   - Political entity for that location
   - Current timezone policy

Of those, coordinates are the only thing that doesn't change over time (for the spans we're talking about).

But are also a pain in the ass to use. F.ex. I'm sure someone on HN has the lat long for London memorized, but I don't.

London is perhaps the only major city where you could be expected to know one of these coordinates. It's defined to have longitude 0.

I suggest giving date and time in the form of phase/frequency references to nearby pulsars. That should guarantee stability for a few million years.

Europe as a whole is too. IIRC there's a set of points around the periphery of the continent that are measured to centimeter accuracy.

The zone database recently had a city spelling change on Kiev to Kyiv

change or adding same entry with the name of city changed ?

Coz change like that could fuck some shit up...

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.

[0] https://github.com/eggert/tz/commit/e13e9c531fc48a04fb8d064a...

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

For example: https://data.iana.org/time-zones/tzdb-2020d/europe (search for Kiev for the specific part; it's a very long file)

I love reading the tz file every now and then, it contains the ultimate time and time zone nerdery.

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.

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].

[0] https://turismo.buenosaires.gob.ar/en/article/what-where-and...

How is it not precisely defined? Lat/long to timezone ought to work... timezones have precise boundaries that cover the whole earth, no?

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).

See (current TimeZone Map):

https://www.timeanddate.com/time/map/

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.

The changing of zones isn't a problem, that's why we're using lat/lon, but if the nearby countries can't agree on what time it is...that's an issue.

I maintain https://github.com/photostructure/tz-lookup which does this task.

*Every single time* I update the tz source file some arbitrary set of zone names and offsets change. Look at the churn and enjoy the schadenfreude: https://github.com/photostructure/tz-lookup/commits/main/tes...

> 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.

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?

    2030-07-01T18:00:00~Scotland/Glasgow ?

> 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.

Suddenly, specifying noon on the third Tuesday on the second full moon after the summer equinox makes sense.

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 think you need to be more specific here.

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.

> 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.

Can't have it all.

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.

I'm well aware. See the footnote.

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.

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.

In the calendar world (iCal), this is actually supported: a date time without a time zone is a local time only [0].

[0]: https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5

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)

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.

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.

You also want a fourth piece of information: what calendar that the specified date belongs to.

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.

This is basically why I ended up rolling my own text date format for Concise Encoding:

- https://github.com/kstenerud/concise-encoding/blob/master/ct...

- https://github.com/kstenerud/concise-encoding/blob/master/ce...

e.g.

    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.

Seconded.

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.

> Anything except Zulu time is basically broken.

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.

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.

> 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 close enough to be useful, more obvious when you have a big offset like +12.

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.

+01:00 doesn't fool you into thinking it's somehow tied to a particular city or politics.

But it does. The only reason people ever use it is because they think it's "my timezone", which works until it doesn't.

No one thinks that +01:00 will magically turn into +02:00.

No, the reason people use it is because they don't want to add the timezone offset and want a timestamp that's intuitive.

> 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.

> 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)

[1] https://news.ycombinator.com/item?id=30045114

"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.

So what is the solution? How does set an appointment to meet someone in London, on July 1st 2030, at 6pm local time?

Date time + lat/long?

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:

   event://de/Berlin/10557/Platz+der+Republic,+1/Bundestag#2030-08-30T18:00

Country borders can change, city divisions can change. Street names can change, and streets can disappear.

Use GPS coordinates instead :D

That won't help if the Bundestag moves into another building. If country borders change, that is also likely to occur :D

Nice idea in theory, but then you need to accommodate for continental drift as well :)

I was expecting that comment and this would be my preferred answer.

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.

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.

Places do not necessarily have a single agreed timezone - see Xinjiang (or indeed Crimea).

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.

>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.

[*] If we ignore leap seconds

Having the tzdata zone at the end, after a space, makes perfect sense. I think you just invented the new standard?

A wall clock / human readable time without a TZ is like a…

…a horse without a field?

…a burger without knowing the meat?

…a photograph of a star without a position?

…a lover without a name? Ok maybe too far.

…a bonus without knowing the currency?

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 standard could simply allow county/city specifiers. or GPS coordinates.

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.

https://en.m.wikipedia.org/wiki/Tz_database

Even this is not enough for some edge cases like “I shall take my supper every day at 6pm, Jeeves” but one can always find exceptions to anything.

It's not in ISO-8601.

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.

... which means ISO 8601 cannot deal with timezones but only UTC offsets - which are temptingly useful but fundamentally broken.

Including fixed UTC offsets was a massive mistake and it should have never happened. Anything except named timezones is useless.

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.

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.

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.

What if London doesn't exist by the event time?

Then the scheduled time is probably irrelevant so who cares

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.

The real world is messy. We can't even predict when the sun will be overhead at any given location a decade or so in advance.

This is why I left computer science research. I realized I was working on things that only made sense inside the machine.

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.

> What if London doesn't exist by the event time?

Europe/London will be either be left alone for historical purposes, or aliased to its successor for backwards compatibility.

See Type: Link and Source file: backward:

* https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

Might be hard to meet there without radiation protection.

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.

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).)

Yes, the city is chosen to be the most populous in the time zone. There’s a long discussion of the policy in https://www.ietf.org/timezones/theory.html

I'm content for that to be a failure mode of the format. :-)

> What if London doesn't exist by the event time?

Or what if it's split into two cities, which half were you talking about? This has famously happened with Berlin.

There are a few ways to represent that in the database, see[1]. Unless I misunderstood what you mean by “no way to specify”.

[1]: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

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.

One complication with that format is that local time can be ambiguous or not exist at all, if the time is during DST switching.

Add one extra bit to store “disambiguation”.

Value 0 meaning “if there is a DST switch, interpret the time as the chronologically earlier one”

Value 1 meaning “if there is a DST switch, interpret the time as the chronologically later 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 ;)

Is LocalDate + LocalTime not sufficient? It seems like if you defer to computation of the instant that would be fine

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.

Potential RFC idea?

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.)

Look far enough into the future and there might not be a London. Or even Europe.

It is an extreme example but if you look at e.g. certain parts of Africa or Middle East…

I usually solve this by storing an explicit named timezone in an additional field.

Hmm. A given UTC time, plus "in London" does do the trick..

Why do you think you can't do that ?

This is supported in Google Calendar. You set the TZ when you're creating an invite.

Reply on news.ycombinator.com