[HN Gopher] Storing Times for Human Events
___________________________________________________________________
Storing Times for Human Events
Author : kiyanwang
Score : 53 points
Date : 2024-12-09 09:18 UTC (2 days ago)
(HTM) web link (simonwillison.net)
(TXT) w3m dump (simonwillison.net)
| Etheryte wrote:
| 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 wrote:
| 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)
| Aachen wrote:
| 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?
| vunderba wrote:
| 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.
| simonw wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| amalcon wrote:
| 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 wrote:
| 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 wrote:
| 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.
| efitz wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| efitz wrote:
| 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)
| simonw wrote:
| 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.
| simonw wrote:
| 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.
| layer8 wrote:
| 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.
| 1propionyl wrote:
| Another good article that discusses the same topic in detail:
| https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
| wavemode wrote:
| 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.
| Swizec wrote:
| > 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.
| gioazzi wrote:
| 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.
| eieio wrote:
| 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.
___________________________________________________________________
(page generated 2024-12-11 23:00 UTC)