15 ms·

Storing Times for Human Events

168 points by kiyanwang 2y ago

amalcon 2y ago
I once was hours late for a doctor appointment, because I entered it into my calendar app while on vacation. That taught this particular lesson pretty effectively.
- happytoexplain 2y ago
  The choice to mash absolute time and clock time into the same formats and APIs is one of the greatest mistakes in the history of programming, somewhere under null pointers.
- somehnguy 2y ago
  I recently had a similar experience on vacation. I entered all of the shows and events I was attending in Vegas into my iOS calendar while home in NY. Upon arriving all my events were 3 hours off, and I had to manually correct each one. A cursory look through Calendar didn’t turn up any way to enter time zone independent events.
  - canucker2016 2y ago
    Same thing happened to me on Android. But Google Calendar also had the time for the departure and reurn flights blocked out (including departure airport/arrival airport both ways), yet it was too dumb to notice I was setting an appt for 8PM for a Las Vegas location - but Google Calendar decided to put an Eastern USA timezone on the appt. That's how you know the Google Calendar devs/PMs don't travel often. And also none of the same Google devs/PMS cared enough nor high-level Google execs themselves use Google Calendar - cuz if they had the same thing happen to them, you'd know that it would have been fixed before the next performance review.
Etheryte 2y ago
A common pitfall I see developers stumble on is underestimating how often timezones, DST rules, etc change. In most of our daily lives this is something that happens very rarely, right? However, if you go look at the change logs for DST rules, timezones, etc, you'll see that as a ballpark figure there's at least one change a year, and on many years more. Once a year is way too often to not account for this data changing and the recommendations given in this article are solid.
RayeEvtuch 2y ago
I think this is a really good approach to handling events that someone might invite someone else to in real life. No one really ever talks about time zone or daylight savings time when you're texting your friend about a party that's happening. It's always obvious from context. I've been working on an end-to-end encrypted event invitation service and I chose to ignore timezones completely and just have a date picker and free-form text field for time. If users want to export the event as an ical file I just set it as an all-day event and put the time in the body of the event. It's not perfect, but it's usable enough for most people. The one exception here is importing to Google Calendar which for some awful reason imports all day events with no time zone as 24 hour long events from 12am to 12am UTC the following day. (I have a silly beta version of the app up at https://pinvite.app https://pinvite.app if anyone cares to try it out)
Aachen 2y ago
It's an interesting article I read and shared with friends when I first saw it, and recommend anyone to read who is not already knowledgeable on the topic, but eh https://news.ycombinator.com/item?id=42259689 https://news.ycombinator.com/item?id=42259689 14 days ago https://news.ycombinator.com/item?id=42281983 https://news.ycombinator.com/item?id=42281983 11 days ago https://news.ycombinator.com/item?id=42358025 https://news.ycombinator.com/item?id=42358025 3 days ago https://news.ycombinator.com/item?id=42364372 https://news.ycombinator.com/item?id=42364372 reportedly 3 days ago but it's the same HN item ID as this one (second chance pool maybe?) It's barely 2 weeks old, is it worth reposting that often? Semi-related, I remember submitting something I found interesting that had been posted iirc ~40 days ago, but had barely gotten any votes so I submitted it once more and i just get redirected to the old ID and the system refuses to create a new entry. Okay no problem, I'll post later^W^W forget about it, but that makes me wonder: how can 4 submissions in two weeks even physically happen?
- vunderba 2y ago
  It would be nice if HN took advantage of the fast Algolia search as the person is typing in the "Submit URL Field" to show the last time(s) it has been submitted in chronological order to help make a better informed decision as to whether something is worth submitting in the first place.
  - throwup238 2y ago
    That's on the roadmap, circa 2045. We just got unpaginated threads after several decades so it'll be a while before the developer cooldown is up.
- simonw 2y ago
  Yeah, I think that's a bit weird too. Note that this is my article but none of those submissions were by me. Maybe Hacker News needs to extend the time period during which it checks for duplicate URLs?
- lcnPylGDnU4H9OF 2y ago
  > second chance pool maybe? It appears to be so. You can hover your cursor over the relative time of the post to see an absolute date which does not change.
Veserv 2y ago
It is important to note that this is only relevant for future events where legal/civil time, a means for squishy humans to coordinate actions in the future, is what matters. For instances like “bake my bread for one hour” you care about elapsed time/duration which is not subject to the whims of civil time as you are coordinating with the laws of physics, or gods of cooking fickle as they may be, so a absolute second offset such as TAI should be used. And for the past, the unambiguous correct answer is TAI or other absolute second offset. Period. This is because the exact time of occurrence of a past event is, ignoring relativity, fixed and corresponds to a specific second/time. This is completely unambiguous and can be converted, entirely losslessly and roundtripped, to whatever the corresponding civil time would have been in any timekeeping system you so desire. But again, this applies to the past only. The mapping between seconds to civil time and vice versa is subject to the whims of your government until then.
- happytoexplain 2y ago
  The relationship between absolute points in time and calendar/clock/tz components can be legally changed retroactively. Just like with any other kind of data, store whatever you are semantically representing. If you are representing an absolute point in time (bread timer), store a Unix timestamp. If you are representing time components, AKA relative time, AKA human time, AKA calendar/clock/tz time, then store those components. Also, most past clock times we care to store start out as future times.
  - Veserv 2y ago
    The relationship between the occurrence of a past event and the second it occurred can not be changed, barring relativity. As such, storing the absolute second offset unambiguously persists the actual time the event occurred regardless of any legal changes. It will just convert to a different, now agreed upon, civil time according to the calendar chosen. It is no different from citing the current second according to the Gregorian calendar versus the Mayan calendar. They both refer to the same “time”, but use different civil dates. The underlying thing that is convertible to different calendar formats is the real thing and corresponds to the absolute time of the past event. edit: And no, it is almost guaranteed that most past time events are timestamps of the “current” time which has the same qualities as “past” time. Only future civil times should not use absolute second offset times.
efitz 2y ago
I’ve thought about the proposed solution before (spoiler: the author proposes to store the user’s intended date/time AND the TZ qualified date/time.) The problem is that, except for UTC, any timestamp relating to a user’s intention must ALSO store a geolocation. Dinner at 6pm? Great! Where (on earth)? And I’m not sure what to make of storing a TZ qualified timestamp AND a non-TZ qualified timestamp. I’m not sure what problem that solves or how to reconcile if they differ. I’m still in the “store as UTC” and be very careful about disambiguating at creation time.
- 9dev 2y ago
  So I’ve been wondering this for a while. Why don’t we actually use a „spacetime“ format, like 2024-12-05T23:03:47+48.86,2.34 instead of bothering with time zones at all? Why not use arbitrary precision coordinates in their place? That would solve a bunch of issues with time zones at once, like not needing to know which time offset existed at the point in time in question. Depending on the use case, we could make the coordinates more precise, but regularly, I’d wager one or two digits would suffice for current timestamp usage.
  - iforgotpassword 2y ago
    But then you'd still need to figure out in what timezone those coordinates are to know when it is/was, so you made the problem even more complex. Unless you're suggesting we get rid of timezones in general, in which case it would be the same time everywhere and we don't need anything for disambiguation, i.e. we can get rid of the coordinates. Inb4 that other blog post that explains why getting rid of timezones is troublesome in everyday life.
    - wongarsu 2y ago
      It's more complex, but usually it better matches user intent. If I say the conference starts on 2027-04-05 13:09 in Berlin, and Germany decides to change their time zones or daylight saving time rules sometime in 2025, your stored offset or stored UTC time is now wrong. The conference will start whenever local clocks show 13:09, and you have no reliable way of knowing which time zone local clocks will be in in two years time. Of course if we go down that path we should also add a format to indicate offsets. If I say I'll be back in 10 minutes, that interval shouldn't change no matter what happens to the time zone. To perfectly disambiguate it you would need to store it as current time (with timezone or UTC) plus the intended offset. This would also "solve" a lot of issues around leap seconds and the inability to predict them more than six months into the future.
1propionyl 2y ago
Another good article that discusses the same topic in detail: 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...
- canucker2016 2y ago
  And previous threads on HN for that URL (oldest first): https://news.ycombinator.com/item?id=19500640 https://news.ycombinator.com/item?id=19500640 https://news.ycombinator.com/item?id=30659164 https://news.ycombinator.com/item?id=30659164 https://news.ycombinator.com/item?id=41043499 https://news.ycombinator.com/item?id=41043499
wavemode 2y ago
One glaring omission from many tools for modeling chronology is that we have date, and datetime, but often don't have a type for just "time". Sometimes you really just want to express that something is going to happen at a certain time, regardless of timezone. If I set my alarm for 7:45 am, I need it to ring when the clock says 7:45 am, wherever in the world I happen to be. This is how most human beings think about time - school starts at 8 am, work starts at 9 am, McDonald's serves breakfast until 10 am, my doctor's appointment is at 4pm... these are all things that remain constant regardless of whether daylight savings time starts or ends, whether our business changes locations to a different state, whether we are conquered by the Romans and our calendar changes... so they should be stored as such, without a timezone attached. Then from there you can combine a "date" and a "time" and a "location / timezone" to form a "datetime", to figure out the actual technological instant something needs to happen, based on the user's location and/or the location the event is going to take place.
- deleted 2y ago
  [deleted]
- Swizec 2y ago
  > Sometimes you really just want to express that something is going to happen at a certain time, regardless of timezone. If I set my alarm for 7:45 am, I need it to ring when the clock says 7:45 am, wherever in the world I happen to be. One of my toughest engineering projects was a system that supports “every Thursday at 3pm” and the participants can be in different timezones with different DST rules. I learned more about time math and how humans think about this stuff than I ever cared to know.
  - dotancohen 2y ago
    Please share!
- pchristensen 2y ago
  I wrote a library ClockTime at my current job to do this. It's a thin wrapper around a "hh:mm" string for a 24 hour time and a time zone name, with some helpers. We ran into problems like "someone in Chicago is meeting with someone in Arizona at 10am every day." Worked great until daylight savings time, which Arizona does not observe. I've learned way more about how to think about, represent, communicate, store, and translate times than I ever thought was possible, but there are tons of war stories of people who have climbed higher on these Mountains of Madness than I can see through the fog of war.
gioazzi 2y ago
There's an interesting twist to this problem when one is playing with DST! Consider for instance a recurring event that happens every day at 02:30, let's say in Switzerland. On the day DST starts, that event cannot exist, at 01:59 clocks will jump forward to 03:00. Vice versa, on the day DST ends, any time between 02:00 and 02:59 will happen twice.
- Kwpolska 2y ago
  How many real humans would have a recurring event at 02:30 on Sunday?
  - voidUpdate 2y ago
    Some people work night shifts
    - mimischi 2y ago
      And the people that do work night shifts, have their shifts either shortened or extended by an hour as well (at least in Germany, from what I’m aware)
      - canucker2016 2y ago
        Before companies went global 24/7, this was really a rare problem. These days, you could have a global company where some emergency occurs and you have to call a meeting at sometime on Saturday wrt your location timezone, but one of the other locations is several hours ahead of your timezone such that the meeting occurs during/around the transition period for their location's timezone. So, not common at all. But it may happen. That's why they choose the transition times to occur when most of the LOCAL population DOES NOT schedule meetings. I don't think there were any Saturday/Sunday virtual meetings when this timezone stuff was created... Simpler times...
- prmph 2y ago
  That's why DST is an abomination which must be abolished. Just say work/school starts at 7am instead of 8am during a part of the year. Simple.
eieio 2y ago
One point from this article that I think is great is: the TZ database maps pretty poorly onto how people think about timezones. In the states, I think most people I know are familiar with "eastern time" or "pacific time." But I doubt that many of my friends recognize "Americas/New_York" or appreciate why they need to select that instead of "Americas/Indianapolis" when referencing eastern time[1]. I certainly wasn't familiar with referencing timezones this way until I had a job that cared a whole lot about timezones and had offices in several countries! I like the idea of solving this by just asking for the location of an event. [1] having lived in indiana a while ago, I'm assuming that Indianapolis gets its own TZ entry because it wasn't on daylight savings back in the 90s (?). Which was pretty annoying.
- deathanatos 2y ago
  The colloquial names people use, in particular "central time", aren't globally unique. I.e., if someone says "central time", to map that to "America/Chicago" usually involves a set of assumptions about being in America in the first place. So, yeah, you either use location, present major nearby cities, etc. to get around the fact that the ordinary person has no idea what the identifier of their timezone is.
  - eieio 2y ago
    Yeah, I think that gets at the fact that it's typically "obvious" what you mean in context - which is part of why I think the TZ database names can feel so off. Why in the world do you need that much precision?! (We of course, both know why! And if you haven't seen the names before but you're a programmer, youprobably still make some assumptions about edge cases, precision, etc. But I'm assuming that is not the experience of the typical Google Calendar user?)
- Terr_ 2y ago
  > I like the idea of solving this by just asking for the location of an event. One issue with this phrasing is that a user might react--quite reasonably--with frustration like: "Gawd, stop asking me you stupid computer, it doesn't matter, I already told you it's an online-only teleconference, it's not really anywhere!" I'm not sure about the best way to phrase it, but ideally we want the user to be answering: "Which clocks determine when the meeting starts?"
bloppe 2y ago
> There’s a variant of this advice which you’re more likely to hear from the PostgreSQL faithful: use TIMESTAMP WITH TIME ZONE or its convenient alias timestamptz. This stores the exact value in UTC and sounds like it might store the timezone too... but it doesn’t! All that’s stored is that UTC value, converted from whatever timezone was active or specified when the value was inserted. This behavior was changed in a more recent edition of the SQL standard. Now, we have `TIMESTAMP WITH LOCAL TIME ZONE` which works the way `TIMESTAMP WITH TIME ZONE` used to work: basically just converting everything to/form UTC when it's stored/retrieved. The semantics for `TIMESTAMP WITH TIME ZONE` are now supposed to work more like the author's suggested approach: just gluing a time zone name to a regular old timestamp. I'm not sure when Postgres will adopt the newer type semantics. Oracle has for a while now: https://docs.oracle.com/en/database/oracle/oracle-database/19/nlspg/datetime-data-types-and-time-zone-support.html https://docs.oracle.com/en/database/oracle/oracle-database/1...
- marcosdumay 2y ago
  What are you talking about? Timestamp with local time zone is exactly the semantics that is broken and can corrupt your data by just having a server set-up wrong. Postgres has had that exact semantics for ages, and the documentation explicitly tells you in very large text that it only exists for compatibility reasons and that you shouldn't use it. The correct semantics for "timestamp with local time zone" is the naive one, that you can only recover using strings nowadays, thanks to the SQL standard braindead decision. But the good (?) news is that if you have a problem that requires a database, it's very likely that you will need to handle time zones anyway, so it's not a big issue.
  - bloppe 2y ago
    I can't actually tell what you're saying. Postgres doesn't have a timestampltz. Only timestamptz. Oracle has both, but their timestampltz behaves like Postgres' timestamptz, and their timestamptz behaves the way the author is suggesting people should handle timestamps. Oracle is using the newer ISO semantics. I wish it were easier to get a copy of the ISO standard I used to access at work.
PBnFlash 2y ago
I had a little page that would encode Unix time of the event in the url, then just count down. Super reliable.
- sandblast 2y ago
  Doesn't really solve the problem mentioned, does it? I decide to generate a link which counts down to doctor's appointment 8 months from now, and in 6 months my country decides to change DST rules. The countdown is now wrong.
prmph 2y ago
> And if some legislature somewhere on earth makes a surprising change to their DST rules, we can identify all of the events that are affected by that change and update that denormalized UTC time accordingly. And how do we automate getting to know about, and performing, those updates in our application databases? If that is not easily automatable, I think storing the UTC time as well will cause problems. Maybe the UTC time should be a calculated column?
- simonw 2y ago
  I suggest storing a "denormalized UTC time", a calculated column would work fine for that. For automation: install the latest tz database (I use pytz for this, usually) and then run a batch job to see what's changed. Not trivial but not impossible either. Running events websites is hard!
jarjoura 2y ago
I was hoping this article would cover non-obvious date time quirks when conveying this to humans. If the context is an event, what does midnight mean? A one-day event might start at 6pm but not end until 2 or 3am. A computer considers that a two-day event, but that's kind of intuitively wrong. To a human, it's only a 1 day, and it doesn't end tomorrow. It ends, late tonight. What if it starts Saturday at 9pm and goes until 6am? You would still consider that a Saturday event, but ends at sunrise, or early morning.
phiresky 2y ago
I think one very common situation you are missing in "Things that can go wrong" is repeating events: If an event repeats every Sunday at 8pm, people expect that to stay at 8pm local time. Which means you need to know the original timezone the event was created in and make sure the interval is counted in local time, respecting DST. A `timestamptz` field is not enough for that, you need the additional `timezone` storage. Another thing that I think is useful to mention is the new extensions to ISO8601 time formatting that allow you to include the actual time zone specifier, which is now finally being standardized: https://tc39.es/proposal-temporal/docs/strings.html https://tc39.es/proposal-temporal/docs/strings.html 2007-12-03T10:15:30+01:00[Europe/Paris] > Because of this format's long-term industry adoption, it was chosen for use in ECMAScript Temporal for both input and output. > Although neither ISO-8601 nor RFC 3339 specifications currently use this syntax, it's on a standards track led by the IETF SEDATE working group which includes ECMAScript Temporal champions as well as other industry participants. It is very important to use a high quality time library that forces you to think about these things.
- michael1999 2y ago
  That's a nice extinction to ISO 8601.

168 points by kiyanwang 2y ago

I once was hours late for a doctor appointment, because I entered it into my calendar app while on vacation. That taught this particular lesson pretty effectively.

happytoexplain 2y ago
The choice to mash absolute time and clock time into the same formats and APIs is one of the greatest mistakes in the history of programming, somewhere under null pointers.
somehnguy 2y ago
I recently had a similar experience on vacation. I entered all of the shows and events I was attending in Vegas into my iOS calendar while home in NY. Upon arriving all my events were 3 hours off, and I had to manually correct each one. A cursory look through Calendar didn’t turn up any way to enter time zone independent events.
- canucker2016 2y ago
  Same thing happened to me on Android. But Google Calendar also had the time for the departure and reurn flights blocked out (including departure airport/arrival airport both ways), yet it was too dumb to notice I was setting an appt for 8PM for a Las Vegas location - but Google Calendar decided to put an Eastern USA timezone on the appt. That's how you know the Google Calendar devs/PMs don't travel often. And also none of the same Google devs/PMS cared enough nor high-level Google execs themselves use Google Calendar - cuz if they had the same thing happen to them, you'd know that it would have been fixed before the next performance review.

Etheryte 2y ago

A common pitfall I see developers stumble on is underestimating how often timezones, DST rules, etc change. In most of our daily lives this is something that happens very rarely, right? However, if you go look at the change logs for DST rules, timezones, etc, you'll see that as a ballpark figure there's at least one change a year, and on many years more. Once a year is way too often to not account for this data changing and the recommendations given in this article are solid.

RayeEvtuch 2y ago

I think this is a really good approach to handling events that someone might invite someone else to in real life. No one really ever talks about time zone or daylight savings time when you're texting your friend about a party that's happening. It's always obvious from context. I've been working on an end-to-end encrypted event invitation service and I chose to ignore timezones completely and just have a date picker and free-form text field for time. If users want to export the event as an ical file I just set it as an all-day event and put the time in the body of the event. It's not perfect, but it's usable enough for most people. The one exception here is importing to Google Calendar which for some awful reason imports all day events with no time zone as 24 hour long events from 12am to 12am UTC the following day. (I have a silly beta version of the app up at https://pinvite.app https://pinvite.app if anyone cares to try it out)

Aachen 2y ago

It's an interesting article I read and shared with friends when I first saw it, and recommend anyone to read who is not already knowledgeable on the topic, but eh https://news.ycombinator.com/item?id=42259689 https://news.ycombinator.com/item?id=42259689 14 days ago https://news.ycombinator.com/item?id=42281983 https://news.ycombinator.com/item?id=42281983 11 days ago https://news.ycombinator.com/item?id=42358025 https://news.ycombinator.com/item?id=42358025 3 days ago https://news.ycombinator.com/item?id=42364372 https://news.ycombinator.com/item?id=42364372 reportedly 3 days ago but it's the same HN item ID as this one (second chance pool maybe?) It's barely 2 weeks old, is it worth reposting that often? Semi-related, I remember submitting something I found interesting that had been posted iirc ~40 days ago, but had barely gotten any votes so I submitted it once more and i just get redirected to the old ID and the system refuses to create a new entry. Okay no problem, I'll post later^W^W forget about it, but that makes me wonder: how can 4 submissions in two weeks even physically happen?

vunderba 2y ago
It would be nice if HN took advantage of the fast Algolia search as the person is typing in the "Submit URL Field" to show the last time(s) it has been submitted in chronological order to help make a better informed decision as to whether something is worth submitting in the first place.
- throwup238 2y ago
  That's on the roadmap, circa 2045. We just got unpaginated threads after several decades so it'll be a while before the developer cooldown is up.
simonw 2y ago
Yeah, I think that's a bit weird too. Note that this is my article but none of those submissions were by me. Maybe Hacker News needs to extend the time period during which it checks for duplicate URLs?
lcnPylGDnU4H9OF 2y ago
> second chance pool maybe? It appears to be so. You can hover your cursor over the relative time of the post to see an absolute date which does not change.

Veserv 2y ago

It is important to note that this is only relevant for future events where legal/civil time, a means for squishy humans to coordinate actions in the future, is what matters. For instances like “bake my bread for one hour” you care about elapsed time/duration which is not subject to the whims of civil time as you are coordinating with the laws of physics, or gods of cooking fickle as they may be, so a absolute second offset such as TAI should be used. And for the past, the unambiguous correct answer is TAI or other absolute second offset. Period. This is because the exact time of occurrence of a past event is, ignoring relativity, fixed and corresponds to a specific second/time. This is completely unambiguous and can be converted, entirely losslessly and roundtripped, to whatever the corresponding civil time would have been in any timekeeping system you so desire. But again, this applies to the past only. The mapping between seconds to civil time and vice versa is subject to the whims of your government until then.

happytoexplain 2y ago
The relationship between absolute points in time and calendar/clock/tz components can be legally changed retroactively. Just like with any other kind of data, store whatever you are semantically representing. If you are representing an absolute point in time (bread timer), store a Unix timestamp. If you are representing time components, AKA relative time, AKA human time, AKA calendar/clock/tz time, then store those components. Also, most past clock times we care to store start out as future times.
- Veserv 2y ago
  The relationship between the occurrence of a past event and the second it occurred can not be changed, barring relativity. As such, storing the absolute second offset unambiguously persists the actual time the event occurred regardless of any legal changes. It will just convert to a different, now agreed upon, civil time according to the calendar chosen. It is no different from citing the current second according to the Gregorian calendar versus the Mayan calendar. They both refer to the same “time”, but use different civil dates. The underlying thing that is convertible to different calendar formats is the real thing and corresponds to the absolute time of the past event. edit: And no, it is almost guaranteed that most past time events are timestamps of the “current” time which has the same qualities as “past” time. Only future civil times should not use absolute second offset times.

efitz 2y ago

I’ve thought about the proposed solution before (spoiler: the author proposes to store the user’s intended date/time AND the TZ qualified date/time.) The problem is that, except for UTC, any timestamp relating to a user’s intention must ALSO store a geolocation. Dinner at 6pm? Great! Where (on earth)? And I’m not sure what to make of storing a TZ qualified timestamp AND a non-TZ qualified timestamp. I’m not sure what problem that solves or how to reconcile if they differ. I’m still in the “store as UTC” and be very careful about disambiguating at creation time.

9dev 2y ago
So I’ve been wondering this for a while. Why don’t we actually use a „spacetime“ format, like 2024-12-05T23:03:47+48.86,2.34 instead of bothering with time zones at all? Why not use arbitrary precision coordinates in their place? That would solve a bunch of issues with time zones at once, like not needing to know which time offset existed at the point in time in question. Depending on the use case, we could make the coordinates more precise, but regularly, I’d wager one or two digits would suffice for current timestamp usage.
- iforgotpassword 2y ago
  But then you'd still need to figure out in what timezone those coordinates are to know when it is/was, so you made the problem even more complex. Unless you're suggesting we get rid of timezones in general, in which case it would be the same time everywhere and we don't need anything for disambiguation, i.e. we can get rid of the coordinates. Inb4 that other blog post that explains why getting rid of timezones is troublesome in everyday life.
  - wongarsu 2y ago
    It's more complex, but usually it better matches user intent. If I say the conference starts on 2027-04-05 13:09 in Berlin, and Germany decides to change their time zones or daylight saving time rules sometime in 2025, your stored offset or stored UTC time is now wrong. The conference will start whenever local clocks show 13:09, and you have no reliable way of knowing which time zone local clocks will be in in two years time. Of course if we go down that path we should also add a format to indicate offsets. If I say I'll be back in 10 minutes, that interval shouldn't change no matter what happens to the time zone. To perfectly disambiguate it you would need to store it as current time (with timezone or UTC) plus the intended offset. This would also "solve" a lot of issues around leap seconds and the inability to predict them more than six months into the future.

1propionyl 2y ago

Another good article that discusses the same topic in detail: 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...

canucker2016 2y ago
And previous threads on HN for that URL (oldest first): https://news.ycombinator.com/item?id=19500640 https://news.ycombinator.com/item?id=19500640 https://news.ycombinator.com/item?id=30659164 https://news.ycombinator.com/item?id=30659164 https://news.ycombinator.com/item?id=41043499 https://news.ycombinator.com/item?id=41043499

wavemode 2y ago

One glaring omission from many tools for modeling chronology is that we have date, and datetime, but often don't have a type for just "time". Sometimes you really just want to express that something is going to happen at a certain time, regardless of timezone. If I set my alarm for 7:45 am, I need it to ring when the clock says 7:45 am, wherever in the world I happen to be. This is how most human beings think about time - school starts at 8 am, work starts at 9 am, McDonald's serves breakfast until 10 am, my doctor's appointment is at 4pm... these are all things that remain constant regardless of whether daylight savings time starts or ends, whether our business changes locations to a different state, whether we are conquered by the Romans and our calendar changes... so they should be stored as such, without a timezone attached. Then from there you can combine a "date" and a "time" and a "location / timezone" to form a "datetime", to figure out the actual technological instant something needs to happen, based on the user's location and/or the location the event is going to take place.

deleted 2y ago
[deleted]
Swizec 2y ago
> Sometimes you really just want to express that something is going to happen at a certain time, regardless of timezone. If I set my alarm for 7:45 am, I need it to ring when the clock says 7:45 am, wherever in the world I happen to be. One of my toughest engineering projects was a system that supports “every Thursday at 3pm” and the participants can be in different timezones with different DST rules. I learned more about time math and how humans think about this stuff than I ever cared to know.
- dotancohen 2y ago
  Please share!
pchristensen 2y ago
I wrote a library ClockTime at my current job to do this. It's a thin wrapper around a "hh:mm" string for a 24 hour time and a time zone name, with some helpers. We ran into problems like "someone in Chicago is meeting with someone in Arizona at 10am every day." Worked great until daylight savings time, which Arizona does not observe. I've learned way more about how to think about, represent, communicate, store, and translate times than I ever thought was possible, but there are tons of war stories of people who have climbed higher on these Mountains of Madness than I can see through the fog of war.

gioazzi 2y ago

There's an interesting twist to this problem when one is playing with DST! Consider for instance a recurring event that happens every day at 02:30, let's say in Switzerland. On the day DST starts, that event cannot exist, at 01:59 clocks will jump forward to 03:00. Vice versa, on the day DST ends, any time between 02:00 and 02:59 will happen twice.

Kwpolska 2y ago
How many real humans would have a recurring event at 02:30 on Sunday?
- voidUpdate 2y ago
  Some people work night shifts
  - mimischi 2y ago
    And the people that do work night shifts, have their shifts either shortened or extended by an hour as well (at least in Germany, from what I’m aware)
    - canucker2016 2y ago
      Before companies went global 24/7, this was really a rare problem. These days, you could have a global company where some emergency occurs and you have to call a meeting at sometime on Saturday wrt your location timezone, but one of the other locations is several hours ahead of your timezone such that the meeting occurs during/around the transition period for their location's timezone. So, not common at all. But it may happen. That's why they choose the transition times to occur when most of the LOCAL population DOES NOT schedule meetings. I don't think there were any Saturday/Sunday virtual meetings when this timezone stuff was created... Simpler times...
prmph 2y ago
That's why DST is an abomination which must be abolished. Just say work/school starts at 7am instead of 8am during a part of the year. Simple.

eieio 2y ago

One point from this article that I think is great is: the TZ database maps pretty poorly onto how people think about timezones. In the states, I think most people I know are familiar with "eastern time" or "pacific time." But I doubt that many of my friends recognize "Americas/New_York" or appreciate why they need to select that instead of "Americas/Indianapolis" when referencing eastern time[1]. I certainly wasn't familiar with referencing timezones this way until I had a job that cared a whole lot about timezones and had offices in several countries! I like the idea of solving this by just asking for the location of an event. [1] having lived in indiana a while ago, I'm assuming that Indianapolis gets its own TZ entry because it wasn't on daylight savings back in the 90s (?). Which was pretty annoying.

deathanatos 2y ago
The colloquial names people use, in particular "central time", aren't globally unique. I.e., if someone says "central time", to map that to "America/Chicago" usually involves a set of assumptions about being in America in the first place. So, yeah, you either use location, present major nearby cities, etc. to get around the fact that the ordinary person has no idea what the identifier of their timezone is.
- eieio 2y ago
  Yeah, I think that gets at the fact that it's typically "obvious" what you mean in context - which is part of why I think the TZ database names can feel so off. Why in the world do you need that much precision?! (We of course, both know why! And if you haven't seen the names before but you're a programmer, youprobably still make some assumptions about edge cases, precision, etc. But I'm assuming that is not the experience of the typical Google Calendar user?)
Terr_ 2y ago
> I like the idea of solving this by just asking for the location of an event. One issue with this phrasing is that a user might react--quite reasonably--with frustration like: "Gawd, stop asking me you stupid computer, it doesn't matter, I already told you it's an online-only teleconference, it's not really anywhere!" I'm not sure about the best way to phrase it, but ideally we want the user to be answering: "Which clocks determine when the meeting starts?"

bloppe 2y ago

> There’s a variant of this advice which you’re more likely to hear from the PostgreSQL faithful: use TIMESTAMP WITH TIME ZONE or its convenient alias timestamptz. This stores the exact value in UTC and sounds like it might store the timezone too... but it doesn’t! All that’s stored is that UTC value, converted from whatever timezone was active or specified when the value was inserted. This behavior was changed in a more recent edition of the SQL standard. Now, we have `TIMESTAMP WITH LOCAL TIME ZONE` which works the way `TIMESTAMP WITH TIME ZONE` used to work: basically just converting everything to/form UTC when it's stored/retrieved. The semantics for `TIMESTAMP WITH TIME ZONE` are now supposed to work more like the author's suggested approach: just gluing a time zone name to a regular old timestamp. I'm not sure when Postgres will adopt the newer type semantics. Oracle has for a while now: https://docs.oracle.com/en/database/oracle/oracle-database/19/nlspg/datetime-data-types-and-time-zone-support.html https://docs.oracle.com/en/database/oracle/oracle-database/1...

marcosdumay 2y ago
What are you talking about? Timestamp with local time zone is exactly the semantics that is broken and can corrupt your data by just having a server set-up wrong. Postgres has had that exact semantics for ages, and the documentation explicitly tells you in very large text that it only exists for compatibility reasons and that you shouldn't use it. The correct semantics for "timestamp with local time zone" is the naive one, that you can only recover using strings nowadays, thanks to the SQL standard braindead decision. But the good (?) news is that if you have a problem that requires a database, it's very likely that you will need to handle time zones anyway, so it's not a big issue.
- bloppe 2y ago
  I can't actually tell what you're saying. Postgres doesn't have a timestampltz. Only timestamptz. Oracle has both, but their timestampltz behaves like Postgres' timestamptz, and their timestamptz behaves the way the author is suggesting people should handle timestamps. Oracle is using the newer ISO semantics. I wish it were easier to get a copy of the ISO standard I used to access at work.

PBnFlash 2y ago

I had a little page that would encode Unix time of the event in the url, then just count down. Super reliable.

sandblast 2y ago
Doesn't really solve the problem mentioned, does it? I decide to generate a link which counts down to doctor's appointment 8 months from now, and in 6 months my country decides to change DST rules. The countdown is now wrong.

prmph 2y ago

> And if some legislature somewhere on earth makes a surprising change to their DST rules, we can identify all of the events that are affected by that change and update that denormalized UTC time accordingly. And how do we automate getting to know about, and performing, those updates in our application databases? If that is not easily automatable, I think storing the UTC time as well will cause problems. Maybe the UTC time should be a calculated column?

simonw 2y ago
I suggest storing a "denormalized UTC time", a calculated column would work fine for that. For automation: install the latest tz database (I use pytz for this, usually) and then run a batch job to see what's changed. Not trivial but not impossible either. Running events websites is hard!

jarjoura 2y ago

I was hoping this article would cover non-obvious date time quirks when conveying this to humans. If the context is an event, what does midnight mean? A one-day event might start at 6pm but not end until 2 or 3am. A computer considers that a two-day event, but that's kind of intuitively wrong. To a human, it's only a 1 day, and it doesn't end tomorrow. It ends, late tonight. What if it starts Saturday at 9pm and goes until 6am? You would still consider that a Saturday event, but ends at sunrise, or early morning.

phiresky 2y ago

I think one very common situation you are missing in "Things that can go wrong" is repeating events: If an event repeats every Sunday at 8pm, people expect that to stay at 8pm local time. Which means you need to know the original timezone the event was created in and make sure the interval is counted in local time, respecting DST. A `timestamptz` field is not enough for that, you need the additional `timezone` storage. Another thing that I think is useful to mention is the new extensions to ISO8601 time formatting that allow you to include the actual time zone specifier, which is now finally being standardized: https://tc39.es/proposal-temporal/docs/strings.html https://tc39.es/proposal-temporal/docs/strings.html 2007-12-03T10:15:30+01:00[Europe/Paris] > Because of this format's long-term industry adoption, it was chosen for use in ECMAScript Temporal for both input and output. > Although neither ISO-8601 nor RFC 3339 specifications currently use this syntax, it's on a standards track led by the IETF SEDATE working group which includes ECMAScript Temporal champions as well as other industry participants. It is very important to use a high quality time library that forces you to think about these things.

michael1999 2y ago
That's a nice extinction to ISO 8601.