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
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?
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.
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.
> 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.
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.
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.
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.
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.
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 if anyone cares to try it out)
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.
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.
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.
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.
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.
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.
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.
My recommendation is actually to store the local time and the exact location, if you can get it. Then use that location to determine the correct timezone.
Some users may not know that their Timezone is America/Los_Angeles but they should hopefully know where their venue is.
You always treat the local time - 6pm on 5th December in Boise, Idaho - as the core truth and derive the UTC version from that. Then if Idaho decide to cancel daylight savings time you can update your calculated and stored UTC timestamps to the correct values.
The location is implied by the time zone. The proposal is to store the user’s calendar date, wall-clock time, and time zone. (Technically, you also need a DST marker for the ambiguous hour in the fall when the clock is turned back and repeats 2–3 am.) From that you can derive a UTC timestamp.
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.
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.
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.
The geo lookup would be expensive computationally, and also there are arguments over geographic boundaries that could make TZ lookup ambiguous (the author gave an example in the article)
> The geo lookup would be expensive computationally
Not really? There's not that many timezones, globally, and I think their polygon data is in OSM / could be obtained from OSM. Simply brute-force colliding a single point with all of them I would expect to be basically "instantaneous", but there are a number of trivial optimizations, like bounding boxes, that you could do to speed it up.
(Point-in-polygon is not terribly expensive; it's O(segments) in your polygon.)
That said, there are problems with that, as you mention. I just don't think "computationally expensive" is one of them.
My recommendation is actually to store the local time and the exact location, if you can get it. Then use that location to determine the correct timezone.
Some users may not know that their Timezone is America/Los_Angeles but they should hopefully know where their venue is.
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 14 days ago
https://news.ycombinator.com/item?id=42281983 11 days ago
https://news.ycombinator.com/item?id=42358025 3 days ago
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?
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.
> 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.
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?
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.
> 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.
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.
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.
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.
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.
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 if anyone cares to try it out)
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.
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.
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.
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.
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.
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.
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.
My recommendation is actually to store the local time and the exact location, if you can get it. Then use that location to determine the correct timezone.
Some users may not know that their Timezone is America/Los_Angeles but they should hopefully know where their venue is.
You always treat the local time - 6pm on 5th December in Boise, Idaho - as the core truth and derive the UTC version from that. Then if Idaho decide to cancel daylight savings time you can update your calculated and stored UTC timestamps to the correct values.
The location is implied by the time zone. The proposal is to store the user’s calendar date, wall-clock time, and time zone. (Technically, you also need a DST marker for the ambiguous hour in the fall when the clock is turned back and repeats 2–3 am.) From that you can derive a UTC timestamp.
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.
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.
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.
The geo lookup would be expensive computationally, and also there are arguments over geographic boundaries that could make TZ lookup ambiguous (the author gave an example in the article)
> The geo lookup would be expensive computationally
Not really? There's not that many timezones, globally, and I think their polygon data is in OSM / could be obtained from OSM. Simply brute-force colliding a single point with all of them I would expect to be basically "instantaneous", but there are a number of trivial optimizations, like bounding boxes, that you could do to speed it up.
(Point-in-polygon is not terribly expensive; it's O(segments) in your polygon.)
That said, there are problems with that, as you mention. I just don't think "computationally expensive" is one of them.
My recommendation is actually to store the local time and the exact location, if you can get it. Then use that location to determine the correct timezone.
Some users may not know that their Timezone is America/Los_Angeles but they should hopefully know where their venue is.
Another good article that discusses the same topic in detail: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...