Hacker News Reader

Comment by et1337 | Hacker News Reader

I think this might be one of those “difficulty curve” memes. On the left, the Padawan: “just use UTC timestamps”. In the center, the journeyman: “no!!! we have to store time zones and translate between them! Time zone awareness!” On the right, the Jedi master: “just use UTC timestamps”.

View on HN

No - the master's answer is that you use one or the other depending on whether you are representing absolute time or clock/calendar time. The expertise lies in understanding the difference between those two things, which one your use case falls into, and how to ensure other developers and the very APIs provided by your platform do not make silent assumptions about that decision.

Often it feels like you can "just use UTC" because it's hard to imagine the fail states, and APIs often make tz assumptions for you so you may never notice those fail states (occasionally your software will just be buggy and annoy a user, decreasing the feeling of quality and trust - it may never result in a disaster).

There is no such thing as absolute time so the distinction you're trying to make is not clear.

Most use cases don't care about relativity

And even then it's difficult. Time zone definitions change. Summer time does not start and end on the same date everywhere. So you also might need to know the UTC offset corresponding to the time zone at that time not just the UTC offset of that time zone today (assuming it still exists)

Edit to add: still, this sounds like a great improvement. A common mistake that naive programmers make is to believe that they can hand-roll their own date/time functions. And JavaScript sort of forces them to do that.

See also Falsehoods programmers believe about time at https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...

It’s not difficult if you understand what you are trying to do conceptually.

For example, if you are trying to say “run this task at this specific time in Los Angeles time” and you put a specific UTC offset, it just doesn’t make any sense. Los Angeles time consists of two offsets, and yet here you openly put down something wrong. You need to put into your system literally Los Angeles time (like America/Los_Angeles) because that’s what you want. You didn’t want an offset. Dear god why are you putting an offset then?

Or you want to define a specific date but then you put into your system a date with a time like 12/12/2024 00:00. Like you started off with “I want to define a specific date” and here you openly just put a time. You had to make up 00:00. Why are you just doing random things without thinking?

I wasn't literally suggesting that you store offsets. Or timestamps. There are way too many weird cases around doing that. But "America/Los_Angeles" is a reference to a file in tzfile(5) format, which contains, among other things, the UTC offset. And a function that produces the correct date and time in Los Angeles at any point in the past has to know (among other things) if that offset was ever anything different, and if it was, when it changed. And many other things.

There are date/time libraries that can't get all of this right, but you'll come a lot closer using them than you will rolling your own.

Don't store raw timestamps. Don't store offsets. Use date/time data types.

In your support: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

While UTC timestamps look like they solve all of the problems in one passing, they have plenty of edge cases that can blow up spectacularly. A good example of this is daylight saving time and countries changing their rules around it. You would think this is a rare occurrence, but it actually happens pretty often [0]! In the last ten years, fourteen countries have abolished daylight saving time.

[0] https://en.wikipedia.org/wiki/Daylight_saving_time_by_countr...

Technically you could use TAI for most things internally and use an offset when you display. It works perfectly for records. The only issue is with scheduled things when your users probably want to point at something in their timezone.

The main problem is that future values of TAI converted into most time zones is nondeterministic. On the other hand, at least you can guarantee all TAI seconds will actually occur.

Or toLocalDisplayString(TAI timestamp). It seems like timezones and their rules change over time and geographic location, using todays rules to show dates back in time with previous rules would be broken right?

Well, any correct time handling library will use something like the IANA timezone database (aka tz/tzdb/zoneinfo) which stores all the changes in timezone rules for localities over the years - a library that only knows "today's rules" would be fundamentally broken as you say. So the internals of toLocalDisplayString(timestamp, timezone, calendar, locale) should look up the appropriate rules in effect at the timestamp and use those to decide the local time to display.

We hit this with the US timezone change in 2005. The front-end devs were using moment.js which didn't know about the previous start/end dates.

These days I try to encode everything that is logically a date as yyyy-mm-dd. And if I need to do math with it, I often work with an offset julian date as an integer. But that only works if you stay on this side of September 1752:

    % cal 09 1752
       September 1752     
    Su Mo Tu We Th Fr Sa  
           1  2 14 15 16  
    17 18 19 20 21 22 23  
    24 25 26 27 28 29 30

Before roughly 100 years ago, calendar dates were region-dependent anyway (Russia was still on the Julian calendar until 1918), and time zones didn’t really exist until roughly 150 years ago (their establishment mostly being motivated by the spreading of railways). It’s okay to apply the perpetual Gregorian calendar both into the past and the future by default. It probably won’t last more than a couple thousand years into the future as well, considering Earth’s decelerating rotation.

Some Orthodox Churches still use the Julian calendar even today. Of course they aren't major software customers.

I think time zones not existing really meant there were infinite time zones, because you use the sun to tell the time.

The solar day varies in length by more than a minute over the year. That doesn't correspond to a well-defined time zone. Also, "zone" implies a geographical area, which meridians arguably aren't.

oof, there went 12 days. at least this isn't a regular occurrence outside of 1752 (unless you have DID, I guess)

If you're truly using Julian dates, the switch to the Gregorian calendar in the UK and US in September 1752 shouldn't affect you.

> if I need to do math with it, I often work with an offset julian date as an integer. But that only works if you stay on this side of September 1752

Wouldn't using Julian days prevent the ordinary problems involved with doing calendar math across a renumbering of the dates?

The mapping from year, month, day that I use (based on the Wikipedia page, but starting on march 1, 1600) doesn't take that gap into account. So the days in that gap exist for me, but we don't deal with dates that far back.

Sure, but now you've reduced the scope of the problem to a few edge cases. Every other solution I've seen still has these edge cases and doesn't solve the core problem as simply as UTC. If you think otherwise, can you describe or provide a link to these other solutions?

For region-specific events (which includes most physical meetings, by convention many financial processes etc.), it's much safer to store both the local time and time zone city, as well as the UTC offset at the time of writing, and to convert to UTC only at runtime using an up-to-date time zone database.

That way, you can identify all of:

- Future timestamps you might want to re-process, e.g. for notification scheduling, because the future UTC conversion has changed between scheduling/updating the event and now.

- Equivalently, timestamps written by software/an OS running an outdated TZ database. You should talk to them; things are about to go wrong if the date is in the non-too-far future!

- Trivially and without conversion, the local time that people will use in the meeting notes, documenting that you missed the meeting because you didn't update your TZ database and dialed in to the meeting an hour late

Like, what if you only need the date but not the time? You can use timestamp to store a birthday, but which in which timezone should you transform it back to date?

Or what if it is specifically about time in timezone independent way? You want to wake up ate 06:00 no matter in any timezone. Just something like alert.

You could use part of ISO8601 like 2020-02-02 or 06:00:00 to store exactly what you specify. But with timestamp, not so much.

I’ve been thinking about this; does a timestamp even work, then, without not only a time zone, but a location? I mean time zones are poor man’s locations, but if we want to do this properly…

Dates of past events are always UTC, dates of future physical events must always be a timestamp and a location, dates of future virtual events are either UTC or location based depending on how virtual they actually are.

I can tell you from bitter experience that if you have an event where a person has to arrive at a place at a time and you store that as UTC instead of wall clock, you will have a problem at some point

Past/future doesn't matter, what matters is context. You don't need to use timezones for ie. setTimeout even though it refers to the future and you should have timezone available for past events ie. atm withdrawal.

setTimeout takes a duration in ms, not a timestamp. If it did take a timestamp, I think you would need to pass it a timezone to disambiguate.

Maybe a better argument is, “when you’re setting a phone alarm, you don’t tell it a timezone.” Maybe the distinction is whether the timezone is established at write time or read time.

Scheduling on a calendar (occur on date X, time Y, in zone Z) and scheduling based on timedelta from instant time (occur exactly X milliseconds before or after instant Y) are both valid, and you can do timedelta scheduling in UTC without needing timezones. The issues come from conflating the two; using timedelta reasoning for calendar scheduling, or using calendar scheduling when you want an exact timedelta.

> when you’re setting a phone alarm, you don’t tell it a timezone.

Which coincidentally and ironically makes phone alarms surprisingly difficult to implement in a way that does not break in the face of DST shifts, timezone changes etc., as Apple has learned the hard way a couple of times.

> Past/future doesn't matter

Past/future does matter, as generally speaking it's possible to accurately convert between local time and UTC for times in the past, but not in the future.

There's a few exceptions where governments have retroactively changed timezones or DST rules, but at that point you've lost anyway.

Yes! All past events have well defined times, even in the face of human silliness like changing timezones and before such ideas existed.

The future is defined by intent which is imprecise (will Oregon drop daylight savings time or not — who knows?). I don’t know how many seconds it is until my next birthday, but I know exactly how many have passed since I was born.

I never really understood precisely what the challenges around dates were until this comment and the previous one.

> the Jedi master: “just use UTC timestamps”.

That poor Jedi master is going to miss the recurring workgroup meeting at least twice per year though, after either DST switch :)

In my experience the Padawan's answer is actually "just use my personal local timezone and don't think about the needs of users elsewhere".

Maybe I'm thinking of a group with less experience than you had in mind, but novices do not even know about UTC.

Sadly UTC doesn’t work with future timestamps because we don’t know if timezones will be adjusted.

Yes that works for most use cases but there are use cases where you may need to store or shuttle the time zone. For instance you want to know this UTC timestamp was originally created in PDT. You would have to store two variables. Most other languages have this functionality it can be useful and is good to have, probably only needed by Jedi’s too.

You can make the same meme about this use case, too. One you get to the right, you realise you want two variables for this.

I have always wondered why breaking the timestamp (in UTC) and the timezone into two separate data points and storing both is not the accepted solution. It appears like the cleanest solution to me.

From my experience, it certainly is. Easy to tell time in sequence as well as local time then. When daylight savings hits you can still calculate well, and can quickly get real time for hours worked out drive time for freight across time zones to follow the hours of service rules.

Two different implementations might make two different local times out of that, e.g. due to not being aware of changing DST/timezone policies. Hence the recommendation of separating between user/clock/calendar time (which must be exact to a human) and absolute/relative timestamps (which must be exact to a computer).

You can't accurately convert future local times to UTC timestamps yet, as that conversion changes when timezones change.

Let's say we schedule a meeting for next year at 15:00 local time in SF. You store that as an UTC timestamp of 2025-08-24 22:00 and America/Los_Angeles timezone. Now, imagine California decides to abolish daylight savings time and stay on UTC-8 next year. Our meeting time, agreed upon in local time, is now actually for 23:00 UTC.

Wow thanks for sharing this, this certainly is a use case not covered by the system I proposed. I imagine this will require versioning of the timezone so we can translate our America/Los_Angeles v1.0 timestamp to America/Los_Angeles v2.0.

The article gives an example, of you buying a coffee with your credit card while travelling to Sydney, and returning to Madrid, and a few months later seeing a charge for 3:50 AM on that date...

Google Photos also get confused with "When was this picture taken?", my older model camera just stores the EXIF date in "local time" and I have to remember to change its timezone when travelling, and if GPhotos can't figure it out, it might show pictures out of the airplane window, and then the next series of pictures are from the departure airport because they're from a "later" hour (since it's missing the timezone info).

I suppose I could keep it at my home time or UTC...

That is how I would expect a bank statement to read though. I would find it infinitely more confusing if I bought something online in my bank showed the time of wherever the seller was located.

The photos problem is harder, but the app needs to just convert it from local time to UTC when you import it. There's not much that can be done if you take photos on a camera with a different time zone than you're in without more metadata.

Yeah, these are workarounds we have to use because many pieces of software weren't implemented fully...

You'll find that most bank systems avoid any notion of time precision higher than calendar days for a variety of reasons :) As a side effect, this practice conveniently avoids that problem entirely.

> That is how I would expect a bank statement to read though. I would find it infinitely more confusing if I bought something online in my bank showed the time of wherever the seller was located.

When using my banking app abroad (one that does show timestamps), I'm usually much more confused by their presence than by their absence.

> The photos problem is harder, but the app needs to just convert it from local time to UTC when you import it.

But I usually want to see the time in local hours and minutes for photos! Sunsets, new year's fireworks etc. happen according to local time, not UTC or my current timezone's offset.

Yeah, storage needs to be implemented in UTC and display needs to be in local time.

But which local time?

Sometimes, the local time at the place the photo was taken can make more sense, but it's not a general rule.

Exif (fun exercise: find out who specifies it and when it was last updated!) actually didn't even have a way of storing timestamps in UTC or with zone information until fairly recently: It was all local times without zone information.

I've seen some software work around that by combining the local date/time with an embedded GPS tag, if present, which does contain the time in UTC.

Ironically, time zones are a hack with bad precision about the position of the sun in the sky. The GPS coordinate side steps the nonsense (can be converted to the time zone as defined in that place at that moment).

And if your spouse is checking the charges from Madrid, they probably want to see it in Madrid time. There is no single correct answer.

Sounds like you are in the middle. Because the Jedi master knows you need both.

This is the language of your engineering team, but not the language of your customer.

Reply on news.ycombinator.com