←back to thread

How to Think About Time in Programming

(shanrauf.com)
189 points rmason | 3 comments | 24 Jun 25 20:01 UTC | HN request time: 0.001s | source
Show context
karmakaze ◴[24 Jun 25 22:21 UTC] No.44371669[source]▶
Two things that aren't really covered:

- system clock drift. Google's instances have accurate timekeeping using atomic clocks in the datacenter, and leap seconds smeared over a day. For accurate duration measurements, this may matter.

- consider how the time information is consumed. For a photo sharing site the best info to keep with each photo is a location, and local date time. Then even if some of this is missing, a New Year's Eve photo will still be close to midnight without considering its timezone or location. I had this case and opted for string representations that wouldn't automatically be adjusted. Converting it to the viewer's local time isn't useful.

replies(1): >>44373641 #
bigiain ◴[25 Jun 25 04:36 UTC] No.44373641[source]▶
The calendar event scheduling problem is hard too.

If I'm in Sydney and I accept a 4pm meeting in 3 weeks time, say 4pm July 15 2025 in San Francisco, how should my calendar store that event's datetime and how does my calendar react to my phone changing locations/timezones?

And now try and work that out if the standard/summertime changeover happens between when the event is created in one timezone and the actual time the event (is supposed to) occur. Possibly two daylight savings time changes if Sydney goes from winter to summer time and San Francisco goes from summer to winter time - and those changeovers don't happen at the same time, perhaps not even the same week.

replies(1): >>44374595 #
1. valenterry ◴[25 Jun 25 07:37 UTC] No.44374595[source]▶
That's easy though. An event of such type is about an absolute point in time, so your calendar stores it like that and then displays it in your current timezone (or whatever one you specify).

When you change locations and you have your calendar configured to show events in "the" timezone of your location, it does so. And should there be no clear timezone, it should ask you.

Very simple problem and simple solutions. There are much harder problems imho.

As you can see, the summertime change does it even matter here.

replies(1): >>44374753 #
2. bigiain ◴[25 Jun 25 08:03 UTC] No.44374753[source]▶
But I don't want my San Francisco meeting to display in my calendar as 1am the day before when I'm in Sydney, then switch to 4pm on Tuesday once I'm in California. And I sure as hell don't want the displayed time in Sydney to switch from 1am to 11pm or 3am just because daylight savings kicked in.

It's a 4pm Tuesday meeting. I want it to show as 4pm while I'm in Sydney, 4pm while I'm on a stopover in Hawaii, and correctly alert me for my 4pm meeting when I'm in San Francisco. And it probably should alert me at 4pm San Francisco time even if I'm not there, in case I missed my connecting flight in Hawaii and I want to call in at the correct time. And that last requirement conflicts wit the "I want it to show as 4pm while I'm on a stopover in Hawaii" requirement, because I'm human and messy and I want the impossible without expending any effort to make it happen.

I'm pretty sure there is no "simple solution" for getting the UX right so I can add a meeting in San Francisco on my phone while I'm in Sydney, and have it "just work" without it always bugging me by asking for timezones.

replies(1): >>44375568 #
3. valenterry ◴[25 Jun 25 10:17 UTC] No.44375568[source]▶
Yeah that's fair, but that's purely a UI/display problem and there is and cannot be any solution that works without context.

Ultimately, if you don't like it, tell your calendar to show it differently.

> It's a 4pm Tuesday meeting

In one timezone, yes.

Apperently you want the times to be shown for when you will be in that timezone. But the calendar doesn't know when you will be in what timezone, and it's such a rare thing that apparently no one made a calendar where you can day "I'll be (mentally) in this timezone from that day and then in that timezone a week later".

So you, your last sentence is right, because that's impossible. That's different from "hard".