Hacker News Reader

Comment by samwillis | Hacker News Reader

I think summary here is that if you are storing an exact moment in time then UTC does the job. If however you are storing a future date and time in a certain location, due to the uncertainty about future daylight saving time changes you have to save it with time zone information in order to adjust for future changes to that system.

I suppose it’s the difference between exact time and social/political time (there is probably a better term for that).

View on HN

Yeah, this is exactly the difference between what I’d call “timestamps” (something that represents a particular instant in time), and what I’d call “datetimes”, things like “midnight on Jan 1, 2019”.

I worked at an insurance startup that stored coverage period start/ends as timestamps, which ended up being semantically wrong. The coverage ends at midnight of the next year, wherever _you_ (technically the provider, I think) are. So there is no one single instant in time when coverage ends; a timestamp is the wrong data type for representing this.

If you've worked on a distributed team that had members in the UK/EU and the USA then you've run into this before when scheduling meetings.

A 10am PDT America/Los_Angeles meeting is different from a 6pm BST Europe/London meeting which is different from a 5pm GMT meeting and those will jump around by an hour depending on time changes. If the bulk of your team is in Seattle then you probably want to pick the US timezone for the meeting and not GMT or London. If you have a manager in London, though, who sets up the meeting time in their local timezone then Seattle employees will notice tomorrow that the meeting is a hour later in Seattle than it normally is.

If everyone shitcanned clocks jumping around twice a year this craziness would end.

I think this is the inverse problem. In this case, timestamp is the appropriate data structure for the meeting and each person's client needs to convert it back to local time, accounting for things like daylight savings time and so on.

Recurring meetings cannot be expressed as timestamps (unless you want all the humans to hate you). The recurrence has to be expressed in terms of local time (and date/day of week) in some (ideally per-event) timezone.

It's fine as long as all the meetings are conventionally expressed in one time zone.

If some meetings are created in some US tz, some other meetings in some EU timezones, then when the biyearly DSTgeddon week(s) come, you not only have meetings shifting unexpectedly but you also have conflicts since some meetings changed and others didn't!

Such a mess. But it doesn't happen frequently enough for it to be worthwhile fixing/regulating/whatever

> If some meetings are created in some US tz, some other meetings in some EU timezones, then when the biyearly DSTgeddon week(s) come, you not only have meetings shifting unexpectedly but you also have conflicts since some meetings changed and others didn't!

But this is a problem in the real world, not a software problem. Choosing to use UTC when that's not how the business actually thinks about schedules will lead to you just doing your own DST math, which is harder than just storing the correct time zones from the get go.

Sure it is a real world problem. And no, I wasn't advocating for UTC which would not work for half a year, instead of causing a few days of minor headaches.

It's caused by the fact that different branches of a large corp have genuine situations where some meetings are between local employees and other situations where you invite a mix of distributed people.

Thus there is no "natural default" as to which timezone is "correct".

Why not? Assuming you mean utc when you say timestamp. You just need to covert it the users timezone before displaying it.

For a repeating meeting I think the construct you want is actually a datetime, generally.

E.g., a weekly meeting is not a meeting that happens on one particular timestamp and then repeats every 24*7 hours. If you hit daylight savings time, you want a 9am meeting to still be on the "new" 9am, not shift to 10am or 8am.

Future times are tricky. Some weekly meetings are 24 hours * 7 days apart. Some are at the same time in (fixed) LocationA, 7 days later; some in (fixed) LocationB. Some in whatever location the organizer is (maybe a personal reminder rather than a meeting with others).

It would be a lot easier if locations changing offsets to other locations was a lot less frequent.

Every calendar app I know asks for a timezone when scheduling a meeting. So if you schedule it in Europe/London, it will move in UTC. If you schedule it in GMT+1 (which what Europe/London is in summer), it won't.

The biggest problem is that for some godawful reason US and Europe have different dates when they go into and from winter time.

Just be glad that the EU managed to unify the dates across the (then) 28 countries.

IIRC in Saudi Arabia the start and end of daylight savings is decided on each year, so not only do you need a historical record, but there's no way to future-proof it without integrating some external source of data, otherwise you'd need to manually add the dates for each year at some point.

We adopted a policy the a `date` type is always interpreted in the reader's local timezone, which is sort how humans think of it anyway; put differently, a `date` type is always relative to the person's watch that is reading said value.

I don't like "datetime", but it's hard to come up with anything better.

Some options:

- local time

- legal time

- calendar time

Yeah I sort of like calendar time as well.

Local time is I think misleading, to my ear it implies something like "a particular datetime in a particular timezone".

"Civil time" is a semi-established term for the combination of date and time, at some (potentially unspecified) location.

https://pkg.go.dev/cloud.google.com/go/civil

There are basically three types of time: coordinated time, based on atomic clocks, zoned time, derived from coordinated time by applying a time zone rule to calculate an offset, and wall clock time. The latter two are often lumped together as local time but are not in practice the same thing.

TZ rules are one way, you can derive zoned time reliably from utc, but not the other way around unless you already know the offset. That’s why seemingly storing utc is best, because you can apply whatever tz rule you want. But, because tz rules are decided by politicians (dst, ramadan, date line shifts, it gets pretty weird, …) and often with little advance notice, tz rule databases are often wrong in practice, which means storing only utc and getting zoned time back out of it reliably is hard. That’s why storing iso timestamps with offsets is best. It preserves both utc and intended local (zoned) time at the time of storing, even if the tz database then changes.

But this is not the author’s problem. They’re dealing with wall clock time. They want to store 9 am and have it always be 9 am, no matter what happens with time zones. That is easy: store the timestamp without tz info. But, the hard part is knowing the instant in time (in coordinated time). Wall clock times may occur twice, so there is no single reliable way to get utc out of it, and even when calculating utc the result can be wrong or become wrong due to the political insanity that is zoned time so it is dangerous to store it and rely on it. You see this problem with anything that schedules people or resources. Something scheduled at 9 am is always 9 am, but if the system needs to send a reminder at 9 am, when do you schedule it? There are no solutions I’m aware of without edge cases.

I solved this for a reservation system by storing wall clock time without offsets and the time zone (id) of the resource separately, and then calculating zoned time for that zone and comparing it with the stored wall clock time every time the instant in time mattered. It worked but was tricky to code.

I think it's even more complicated than that. Human time is much richer even than wall-clock time. E.g., if I go out for a dawn run every day, to me that's the same time. Or think of the Jewish Sabbath, which runs from sundown Friday to after dark on Saturday. Lunchtime. Teatime. Lunar calendars. Whatever people will do when they live on Mars. Or the way wall-clock time existed before railroads changed it.

It's often our job to cram human concepts into a small number of bits, so I get why we do what we do. But I think it's sometimes worth being explicit that the anthropological concepts we are dealing with are very complex, and we may leave a lot out when we simplify them enough to make sense to the sort of machine that can be cheaply built in its era.

Wall clock is solved by having a camera pointed at local live news where local time is shown, and having your system updated periodically where this period is arbitrarily short.

A similar issue can get developers in trouble with dates, specifically the YYYY-MM-DD for a given event. In C# for instance, there used to only be the DateTime, which stored a date AND a time, which was set to 00:00:00. It was on you to know to ignore the time in comparisons and/or always use the DateTime.Date method to compare with a 00:00 DateTime. This was fixed with the introduction of DateOnly (https://docs.microsoft.com/en-us/dotnet/api/system.dateonly?...).

Databases usually have types to represent just dates or dates/times. Always use the lowest resolution type to represent what you actually are trying to capture.

> Wall clock times may occur twice

Rule number one and the only rule about wall clock times is that they are display style only and must never be stored. Local times must use 24 hour format.

This isn't what they're talking about, though. Say your boss says "your work shift starts at 9am". That isn't an instant in time, it's all about the display rule: clock says 9am and you're not at work, you're fired.

We don't typically care about this because we work 9-5 M-F, and daylight savings time conveniently happens at 2am on Sunday morning. But someone was told to come in at 2am this morning and couldn't actually do that because 1:59:59 became 3:00:00. How do you handle that? It's not a code problem, it's a business rules problem.

No, this is not a display rule. This is the domain data type "local time", which stores time component without offset or time zone.

Data stored this way is basically telling that regardless of current UTC offset, locally on the clock there will be always the same time shown.

Display rules are saying how exactly this time will be displayed on the clock (i.e. locale, 12/24 hour format etc). Wall clocks usually do not show "am/pm" information, so the same time indeed may occur twice on them.

"wall-clock time" does not mean what is shown by a literal wall clock. It means the time used by people who are not computer engineers. https://en.wikipedia.org/wiki/Elapsed_real_time

When the parent comment said "Wall clock times may occur twice", they meant between 2 and 3am when when leaving DST.

I do not think this is what they meant, 24h or 12h+am/pm are equivalent amount of information.

I believe they were referring to the fact that because of DST and other time adjustments, 24h wall clock times can in fact occur twice (or not at all, like this morning).

That is still either display rule or scheduling process topic, rather than a data type issue.

Few examples:

1. Local public transportation systems must commit to certain schedule of departures from every stop and make it unambiguous. This means that they have to always use local time in publicly communicated schedule, but plan the time table in UTC assuming that offsets will not change. Usually results in departures happening twice on the same time, requiring some extra resource planning.

2. Long-range trains and flights must (and usually do) operate in UTC, communicating arrival and departure times via display rules.

3. Shift planning in 24-hour working processes: offsets complicate the planning process and add unnecessary risk of breaking compliance, so they better be avoided and UTC must be used in combination with display rules.

4. Execution of scheduled jobs: depends on recurrence setup, for which display rules must distinguish between "once per day" (local time + take first occurrence on spring offset change) and "every 24 hours" (UTC + display times of occurrence).

It seems to me that you are mostly arguing about what kind of time to use for a given business problem here. This is actually an interesting problem, but it is a business problem.

For example where I live trains will have a 1h delay (sometimes there are buffers that you can use to reduce the delay, or you cancel trains that anyway only run in the time window that is missing) when “springing forward” and will take a 1h break in the middle of the night when “falling back.” The schedule itself doesn’t change. Seems weird to me, but it is how the business rule is.

But what if the business rule is to use wall clock time? And that is actually a sensible choice for things like concerts or dinner appointments in a calendar.

When you use wall clock time (I assume that is what you mean when you call it local time) in example 4 you choose

> local time + take first occurrence on spring offset change

which is _one_ possible way to handle duplicate wall clock times; wall clock times are underspecified which you implicitly admit by choosing the first occurrence. So it _is_ a data type issue, unless you define the wall clock time data type to contain the occurrence number (e.g. something like `2022-10-30 02:32 II`).

To me that’s not a wall clock time but a wall clock time _with occurrence_ (or whatever name you want to give it) and it’s probably not a concept the user will know, so it needs some UX tweaks (e.g. hide the occurrence when there are no duplicate times and when there are notify the user about the ambiguity, offer a default and explicitly state it, maybe allow to change it to the 2nd occurrence, or maybe disallow duplicate times and ask for another time).

Another problem is that when switching forward there are holes in the time line, but that is easier to solve (it’s an invalid input).

> For example where I live trains will have a 1h delay (sometimes there are buffers that you can use to reduce the delay, or you cancel trains that anyway only run in the time window that is missing) when “springing forward” and will take a 1h break in the middle of the night when “falling back.” The schedule itself doesn’t change. Seems weird to me, but it is how the business rule is.

The ferries near me essentially keep the offset for the whole sailing day. The sailing day starts around 5 am, and has a number of trips; service has been reduced during covid, so typical last sailing times are around midnight or 1 AM, but when service continued through DST changes, a 2:30 AM ferry would sail an hour after 1:30 AM, regardless of what local time was then, and so on. The time between the end of Saturday's sailing day and the start of Sunday's sailing day varies due to the time change however. But we don't have 24 hour ferry coverage, so it's easy to keep the schedule aligned without adjusting service.

I think they’re talking about times occurring twice due to DST.

What really bothers me is that the tools we use (databases, time data libraries) have really poor support for wall time. Most of the times, there is no support at all.

That's why people go and store times in UTC (with a separated time zone), and then everything breaks because some tool always expects non-tz data to be on the local tz, or the original system converts tzs behind the scene, or whatever.

> due to the uncertainty about future daylight saving time changes

It’s not just DST, it’s any TZ-related changes: locations can change TZ for other reasons than dst.

> I suppose it’s the difference between exact time and social/political time.

There’s really no such thing as exact time. The closest is UT1, and it’s not really practical for normal applications.

> There’s really no such thing as exact time. The closest is UT1, and it’s not really practical for normal applications.

I would have defined TAI (International Atomic Time) as "exact time". Of course with it being an average of clocks it only really exists in hindsight and isn't perfect either, but if you only need accuracy on the order of hundreds of nanoseconds and are on earth's surface it's very practical and easy to get anywhere with a GPS receiver.

And UTC is only slightly more messy, with its offset from TAI to keep it in sync with unpredictable UT1.

Right. It's crazy that we welded civil time to UT1 rather than TAI. TAI is ours, we made it, here on this rock we're all stuck on. Because time is necessarily relative to your position that's the best we could hope for.

The astronomers are welcome to UT1, it's useful for them and I have no problem with that, but it's crazy to keep tweaking UTC to match UT1 rather than just letting it plod along mechanically forever with TAI. Abolish leap seconds.

This will create problems in the long term, because the delta-T due to the deceleration of earth’s rotation due to tidal friction increases quadratically [1]. Not saying it wouldn’t be practical, but that’s the debate, along with astronomer’s needs, satellite navigation etc. You can’t just ignore the relationship with earth’s rotation.

[1] e.g. https://www.researchgate.net/figure/Observations-and-parabol...

> You can’t just ignore the relationship with earth’s rotation.

Doing so is, in fact, the point of abolishing leap seconds.

Imagine that we have leap seconds, and the very worst case conceivable happens for an entire century. 100 summer leap seconds and 100 winter leap seconds, that's a total of just over three minutes by 2122.

Can we tolerate such a disruption to the lives of ordinary people? Try asking anybody who lives in a place with Daylight Saving or "Summer" Time. They have twenty times more disruption and that happens twice every single year.

Right, but (a) that only defers the problem to the future (centuries), which will have ever faster increasing delta-T, and (b) in the short-term you'd have to change all the existing infrastructure for astronomy and satellites which rely on the broadcast (by NTP or whatever) clock signals to be UTC. There's too much that could break; therefore there's a preference for "never change a running system". Of course, there's disagreement on how well the current system "runs". But it's not as simple as saying "oh, let's just drop leap seconds and everything will be fine".

An increasing delta-T creates more problems for UTC than TAI. UTC can continue to be used for user-facing applications, or ones directly related to e.g. astronomy, but for most unstances of simple timing and time-keeping TAI is what you actually want. Remote systems can gradually be transitioned to TAI clock signals, and not have to bother with leap seconds ever again.

Let's just outlaw deceleration of the earth, and while we are at it, mandate that the sun rises and sets at the exact same time every day.

"Pi is exactly three!! Now that I have your attention..."

> It’s not just DST, it’s any TZ-related changes: locations can change TZ fir other reasons than dst.

Exactly, and for that time zone info will not be enough, you would need geographic coordinates.

To be more accurate you should also store relative velocity so the Lorentz transformation can be applied at display time

Geographic coordinates can change as well (earthquakes; office moves). But that's why the tzdb uses major/dominant city names.

Issue with that is borders move, and with that time zones. So you may be in the “Europe/London” time zone now. But the north of England could annex itself and create a new time zone “Europe/Manchester”…

In the great schism of England, the meeting organizer fled to central Europe, and one of the primary stakeholders died. The meeting had to be rescheduled.

A more realistic issue is that Scotland currently doesn’t have an entry in the tzdb.

Depends on what you mean by time zone info. A time zone identifier like "Europe/Paris" will usually be sufficient.

Time zone identifiers are created once an area stops matching the previously best-matched identifier.

Like right now maybe all of France uses Europe/Paris, but if southern France decides to secede and change their timezone by an hour, they would all have to re-configure from Europe/Paris to Europe/Toulouse. The existence of a bunch of currently seemingly-redundant time zone identifiers are a testament to the history of this.

So the only 100% future-proof solution is geographical coordinates that can be looked up in a continually-updated database.

> geographical coordinates

So, what do you do for a remote meeting with participants in different places? You’d have to decide on one location. Specifying Paris when you are really in Toulouse isn’t much different. Yes, your meeting is now bound to Paris time, but at least it remains consistent with that.

Furthermore, having had to work with call routing based on geolocation, I can tell you that geo coordinates aren’t always enough, due to inaccurate zip code and area code divisions and other factors.

I wander if we need a new version of ISO8601 which includes the TZ location rather than just an offset. Something like:

  2022-03-13T07:21:39@Europe/London

I suppose that’s also problematic if the location changes to a different time zone due to boundary changes. Maybe we need a coordinate (and planetary body) system:

  2022-03-13T07:21:39@Earth/51.5055853,-0.1014699

We need that full frame of reference to be sure we will be correct in future.

I think tzdata timezone locations (like Europe/London) are fully sufficient, since they are tracking the clock everyone uses in that location. If the boundaries change, then so will the clock for everyone in that boundary, so the time probably won't be right regardless.

I think coordinates are not completely right, since the time context is mostly political/cultural, not geographic. I don't have examples but I can easily imagine a border region specifying some event in a time that is referencing the region across the border.

> I think coordinates are not completely right, since the time context is mostly political/cultural, not geographic.

My point was that geopolitical boundaries change and so what the “major” city near by for reference is now, may be wrong in the future. Coordinates ensure it’s completely future proof from boundary changes and correct to an exact location.

There will always be outliers. If you're scheduling a meeting in a small town on the border of 2 countries that honor different time-zones, then you're probably just going to have to pick one to be the source of truth, and hope it's the other side causing the disruption (changing their clocks) and they'll pay for the administrative overhead.

This happened when Mexico and US stopped being on the same DST schedule - San Diego and Tijuana now have a time difference part of the year.

Well, there's also continental drift :-) honestly everything we do in IT is approximation - some of them are worth accounting for, many are not - at least for most of us.

Sometimes local date-time (with optionally a location) is better. If I tag a photo as Christmas morning and upload it to a global photosharing site, I'd expect something that says when I took it in my local time and optionally location. I don't care about UTC or the photo's timestamp in the viewers timezone. If you want to make it complicated store UTC + offset (not timezone).

Yeah, human time is much more complicated than the strict linear clock. For certain past periods the former can generally be destructively mapped onto the latter. But as with a lot of things, programmers tend to confuse human intent with the post-intent "objective" record of the thing. Which I get, as the latter is much easier to deal with.

I’ve used wall clock time for the latter. Because what matters is the time in the wall clock for future events/meetings.

I don’t know where exactly I picked up the word but I’ve used it here https://news.ycombinator.com/item?id=22968405

> "social/political time (there is probably a better term for that)."

The better term is "civil time": https://en.wikipedia.org/wiki/Civil_time

I called this out in the “how all this relates to programming” part of a presentation I did a couple of years ago on the history of timekeeping.

Just store an offset amount from the start point, create a tangent line against the curve of time, and then as the limit approaches zero…

Yeah, also you can't compare UTC times without an almanac generated by a random natural process which means even without the cultural/political problem UTC is still by definition uncertain for future dates. AST is arguably better for this but doesn't get around the political problem.

I probably should read into details, but I don't get it from the summary at least.

How would future time zone change or DST change affect it at all? Is it about your pre-defined time would no longer be aligned with a nice "local time" like 0:00?

Because things would still happen at the exactly same "moment" (absolute time or time delta from now) in UTC regardless any TZ change isn't it?

Doesn't help you much if you stored an UTC for a future meeting, then the TZ rules change, and then you show up an hour late.

True, although if your meeting will be attended by people in multiple time zones, you need to declare the time in some absolute sense anyway.

The difference is something like storing your comment was made at 2022-03-13+10:40. Which the time zone has been set and will always be the same at as it's in the past vs "set an alarm for 2023-03-13+6:00" I want the to happen at 6:00am whether or not my country continues to observe day light saving time.

You have a timestamp in the future for example the time when a session at a conference starts. If to want to store this as UTC you will have to convert it from the local timezone of the conference location. You can always go back from the UTC timestamp to the local timestamp by performing the reverse conversion EXCEPT if the conversion involves daylight savings and the rule changes between now and the event in the future. While rare, daylight savings rules sometimes do change. I guess even local timezone offsets might change once in a while. When this happens the conversion back from UTC to the local time will be wrong unless you keep track of more than the UTC timestamp.

Reply on news.ycombinator.com