20 ms·

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 w

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 https://en.wikipedia.org/wiki/British_Summer_Time [1] https://en.wikipedia.org/wiki/Central_European_Time https://en.wikipedia.org/wiki/Central_European_Time [2] https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of...

ydnaclementine 3y ago
Potential RFC idea?
gorgoiler 3y ago
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?
- jvanderbot 3y ago
  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.
  - pas 3y ago
    the standard could simply allow county/city specifiers. or GPS coordinates.
  - gorgoiler 3y ago
    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 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.
  - deathanatos 3y ago
    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.
  - crote 3y ago
    ... 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.
    - lxgr 3y ago
      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.
tadfisher 3y ago
What if London doesn't exist by the event time?
- klysm 3y ago
  Then the scheduled time is probably irrelevant so who cares
  - MichaelZuo 3y ago
    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.
    - Mayelitol 3y ago
      [flagged]
    - gumby 3y ago
      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.
      - MichaelZuo 3y ago
        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.
        gumby 3y ago
        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.
klysm 3y ago
Is LocalDate + LocalTime not sufficient? It seems like if you defer to computation of the instant that would be fine
jbandela1 3y ago
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.
- jvanderbot 3y ago
  And so, you want a probabilistic time estimate based on the likelihood of that passing?
  - codetrotter 3y ago
    Store the gps coordinates of the location for the meeting instead, along with the desired local time and local date.
    - jvanderbot 3y ago
      But the local time would change according to GP's comment.
      - codetrotter 3y ago
        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
        jvanderbot 3y ago
        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"
jiehong 3y ago
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 https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5
- codetrotter 3y ago
  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.
- wrs 3y ago
  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.
- Karellen 3y ago
  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?
  - michaelt 3y ago
    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...
    - nightpool 3y ago
      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)
ivan_gammel 3y ago
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
- codetrotter 3y ago
  Country borders can change, city divisions can change. Street names can change, and streets can disappear. Use GPS coordinates instead :D
  - rini17 3y ago
    That won't help if the Bundestag moves into another building. If country borders change, that is also likely to occur :D
  - lxgr 3y ago
    Nice idea in theory, but then you need to accommodate for continental drift as well :)
    - ivan_gammel 3y ago
      I was expecting that comment and this would be my preferred answer.
  - ivan_gammel 3y ago
    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.
- jameshart 3y ago
  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.
tonyhb 3y ago
This is supported in Google Calendar. You set the TZ when you're creating an invite.
CodesInChaos 3y ago
One complication with that format is that local time can be ambiguous or not exist at all, if the time is during DST switching.
- codetrotter 3y ago
  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”.
  - CodesInChaos 3y ago
    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.
  - proto_lambda 3y ago
    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 ;)
slim 3y ago
Why do you think you can't do that ?
ainar-g 3y ago
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-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
LegionMammal978 3y ago
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-extended-09.html https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e... [1] https://tc39.es/proposal-temporal/docs/strings.html#iana-time-zone-names https://tc39.es/proposal-temporal/docs/strings.html#iana-tim... [2] https://tc39.es/proposal-temporal/docs/ambiguity.html#ambiguity-caused-by-permanent-changes-to-a-time-zone-definition https://tc39.es/proposal-temporal/docs/ambiguity.html#ambigu...
- seabass-labrax 3y ago
  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?
  - LegionMammal978 3y ago
    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.
danbruc 3y ago
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.
- codeflo 3y ago
  > 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.
  - danbruc 3y ago
    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?
    - codeflo 3y ago
      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?
the_duke 3y ago
I usually solve this by storing an explicit named timezone in an additional field.
deathanatos 3y ago
> 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.
- WirelessGigabit 3y ago
  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.
  - wahern 3y ago
    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.
    - deathanatos 3y ago
      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.)
mike_hock 3y ago
> 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.
- koliber 3y ago
  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.
- crote 3y ago
  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.
  - mike_hock 3y ago
    > 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.
deleted 3y ago
[deleted]
jameshart 3y ago
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.
crooked-v 3y ago
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.
sublinear 3y ago
> 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.
- Affric 3y ago
  > 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 https://news.ycombinator.com/item?id=30045114
- randallsquared 3y ago
  "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.
hackerbrother 3y ago
Hmm. A given UTC time, plus "in London" does do the trick..
kstenerud 3y ago
This is basically why I ended up rolling my own text date format for Concise Encoding: - https://github.com/kstenerud/concise-encoding/blob/master/cte-specification.md#temporal-types https://github.com/kstenerud/concise-encoding/blob/master/ct... - https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#temporal-types 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.
- lifthrasiir 3y ago
  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.
  - euroderf 3y ago
    Seconded.
mherdeg 3y ago
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.)
mjan22640 3y ago
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.
zaxomi 3y ago
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.
- HelloNurse 3y ago
  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.
kybernetikos 3y ago
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.
- schube 3y ago
  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.
baq 3y ago
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…
zajio1am 3y ago
>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
themeiguoren 3y ago
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.

ydnaclementine 3y ago

Potential RFC idea?

gorgoiler 3y ago

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?

jvanderbot 3y ago
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.
- pas 3y ago
  the standard could simply allow county/city specifiers. or GPS coordinates.
- gorgoiler 3y ago
  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 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.
- deathanatos 3y ago
  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.
- crote 3y ago
  ... 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.
  - lxgr 3y ago
    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.

tadfisher 3y ago

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

klysm 3y ago
Then the scheduled time is probably irrelevant so who cares
- MichaelZuo 3y ago
  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.
  - Mayelitol 3y ago
    [flagged]
  - gumby 3y ago
    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.
    - MichaelZuo 3y ago
      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.
      - gumby 3y ago
        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.

klysm 3y ago

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

jbandela1 3y ago

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.

jvanderbot 3y ago
And so, you want a probabilistic time estimate based on the likelihood of that passing?
- codetrotter 3y ago
  Store the gps coordinates of the location for the meeting instead, along with the desired local time and local date.
  - jvanderbot 3y ago
    But the local time would change according to GP's comment.
    - codetrotter 3y ago
      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
      - jvanderbot 3y ago
        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"

jiehong 3y ago

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 https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5

codetrotter 3y ago
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.
wrs 3y ago
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.
Karellen 3y ago
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?
- michaelt 3y ago
  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...
  - nightpool 3y ago
    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)

ivan_gammel 3y ago

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

codetrotter 3y ago
Country borders can change, city divisions can change. Street names can change, and streets can disappear. Use GPS coordinates instead :D
- rini17 3y ago
  That won't help if the Bundestag moves into another building. If country borders change, that is also likely to occur :D
- lxgr 3y ago
  Nice idea in theory, but then you need to accommodate for continental drift as well :)
  - ivan_gammel 3y ago
    I was expecting that comment and this would be my preferred answer.
- ivan_gammel 3y ago
  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.
jameshart 3y ago
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.

tonyhb 3y ago

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

CodesInChaos 3y ago

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

codetrotter 3y ago
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”.
- CodesInChaos 3y ago
  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.
- proto_lambda 3y ago
  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 ;)

slim 3y ago

Why do you think you can't do that ?

ainar-g 3y ago

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-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

LegionMammal978 3y ago

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-extended-09.html https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e... [1] https://tc39.es/proposal-temporal/docs/strings.html#iana-time-zone-names https://tc39.es/proposal-temporal/docs/strings.html#iana-tim... [2] https://tc39.es/proposal-temporal/docs/ambiguity.html#ambiguity-caused-by-permanent-changes-to-a-time-zone-definition https://tc39.es/proposal-temporal/docs/ambiguity.html#ambigu...

seabass-labrax 3y ago
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?
- LegionMammal978 3y ago
  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.

danbruc 3y ago

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.

codeflo 3y ago
> 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.
- danbruc 3y ago
  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?
  - codeflo 3y ago
    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?

the_duke 3y ago

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

deathanatos 3y ago

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

WirelessGigabit 3y ago
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.
- wahern 3y ago
  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.
  - deathanatos 3y ago
    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.)

mike_hock 3y ago

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

koliber 3y ago
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.
crote 3y ago
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.
- mike_hock 3y ago
  > 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.

deleted 3y ago

[deleted]

jameshart 3y ago

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.

crooked-v 3y ago

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.

sublinear 3y ago

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

Affric 3y ago
> 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 https://news.ycombinator.com/item?id=30045114
randallsquared 3y ago
"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.

hackerbrother 3y ago

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

kstenerud 3y ago

This is basically why I ended up rolling my own text date format for Concise Encoding: - https://github.com/kstenerud/concise-encoding/blob/master/cte-specification.md#temporal-types https://github.com/kstenerud/concise-encoding/blob/master/ct... - https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#temporal-types 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.

lifthrasiir 3y ago
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.
- euroderf 3y ago
  Seconded.

mherdeg 3y ago

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

mjan22640 3y ago

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.

zaxomi 3y ago

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.

HelloNurse 3y ago
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.

kybernetikos 3y ago

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.

schube 3y ago
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.

baq 3y ago

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…

zajio1am 3y ago

>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

themeiguoren 3y ago

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.