[bob1029]

The only situation where our datetime instances deal with timezones is on a one way trip to a user's display, document or email. If you are playing around with parsing timezone strings, you are probably making a huge mistake unless you are parsing someone else's trash data.

I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps. These are trivial to store in any database as a native type, can be compared using the fastest arithmetic instructions possible, and are a locale agnostic representation suitable for direct business logic comparisons.

Trying to carry timezone information around is a mistake. This is state that should be terminated and normalized at both ends, not passed through the system.

The only thing I would store pertaining to timezone is for user profile or server environment configuration. These would be settings in the application that are used to produce locale-specific UI and reports.

There are probably some other use cases I am not thinking of, but that is the extent of how we do it and we have a really complex app that has to serve customers who operate in multiple timezones at once.

[detaro]

Human-decided events in the future are an obvious example. E.g. "every second Tuesday at 8:00" or "May 17, 2025, 8:00" shouldn't ever happen at 7 or 9, even if your software didn't have accurate DST information for that point available initially (which countries do change, sometimes with only a few weeks of warning!).

[tallanvor]

What if you're scheduling a meeting for multiple people, and normally you're in Seattle, but for some of these meetings you'll be in New York? You don't want the meeting to be at 8:00 your time because chances are the people in Seattle aren't going to join your call at 5:00 their time.

[ubermonkey]

As someone who routinely sets meetings for people in multiple timezones, let me say this isn't confusing.

All the calendaring tools I use or am aware of, at this point, keep up with time zone correctly (or have so far). I set the meeting for, say, 10 CST, and it's clear to my colleagues in Seattle that it will be 8 for them, just as it's clear for my coworkers in DC that it'll be 11.

[kevincox]

There are still edge cases.

What if you schedule a meeting in a year's time in a timezone that doesn't have Daylight Savings Time but that government decides to add it and now the meeting is at a time that doesn't exist?

But your use case it also talking about when using a tool that is specifically designed to deal with this issue. What about when you are trying to find a good time (AFAIK most calendars don't have good tooling for collaboratively choosing a meeting time). If you do this in your favourite chat app then you probably have no timezone support. (This would be an awesome feature though)

[Schiendelman]

Real calendar applications handle this by storing the scheduled time as GMT, and the UI adds an offset for where users are. This also solves the problem of you driving between time zones between the time that you schedule the meeting and the time that you attend it.

[kevincox]

The problem is that the GMT time for a future event is unknowable. Timezones change based on the whims of governments. They change rarely, but they do change.

Your calendar can store the GMT time for lookups but it will need to recalculate this if the timezone data changes.

Furthermore it isn't as simple as "storing GMT" for repeating events. As the offset will be different for different occurrences. So you need to store the original timezone for the recurrence rule. (And see the above problem about the absolute time of a current local time being unknowable)

[bslorence]

Twice a year we have to deal with calendar screw-ups because a third of our employees are in a locale that doesn't observe DST and the rest are in locales that do observe it. If an employee from that first group sets up a recurring meeting, the meeting time changes for everyone else in March and November.

[detaro]

A meetings timezone can be independent of a users, yes. E.g. the meeting time should be specified as e.g. "8:00 America/Los_Angeles" (or have a location-based lookup, but thats another level of indirection). That way it follows whatever DST rules there are, but your local phone time being in NY time only affects your display.

[rbanffy]

> Trying to carry timezone information around is a mistake.

No.

If a human says a recurring meeting happens at 9 AM Pacific time and the following week they are in daylight saving time, it'll still happen at 9 AM local time. Preserving intent is crucial in this case.

[arkh]

Even better with "virtual meetings": 9AM in which user timezone? Sometime people move and they still expect the meeting to happen at 9am for them.

[ttymck]

isn't that a local time and not a timestamp/datetime?

[kelnos]

Sort of. If you expect to have to deal with people in other time zones, though, you still need to carry time zone information, so the person who lives in New York will correctly dial in to the meeting at their noon and not their 9am.

(This also raises the point that you need to preserve zone information, not just the UTC offset. Otherwise the meeting will move after a daylight saving time change, which is not usually what people want.)

[kstenerud]

It's not quite so cut-and-dry. UNIX timestamps unfortunately don't solve the problems of time because they don't contain enough information.

Time is something that developers get wrong more often than any other type. Your time data requirements change as your use case for the time changes.

From https://github.com/kstenerud/compact-time/blob/master/compac...

Aside from issues of synchronization, leap seconds, data container limitations and such, it's important to choose the correct kind of time to store, and the right kind depends on what the purpose of recording the time is.

There are three main kinds of time:

*Absolute Time*

Absolute time is a time that is fixed relative to UTC (or relative to an offset from UTC). It is not affected by daylight savings time, nor will it ever change if an area's time zone changes for political reasons. Absolute time is best recorded in the UTC time zone, and is mostly useful for events in the past (because the time zone is now fixed at the time of the event, so it probably no longer matters what specific time zone was in effect).

*Fixed Time*

Fixed time is a time that is fixed to a particular place, and that place has a time zone associated with it (but the time zone might change for political reasons in the future,for example with daylight savings). If the venue changes, only the time zone data needs to be updated. An example would be an appointment in London this coming October 12th at 10:30.

*Floating Time*

Floating (or local) time is always relative to the time zone of the observer. If you travel and change time zones, floating time changes zones with you. If you and another observer are in different time zones and observe the same floating time value, the absolute times you calculate will be different. An example would be your 8:00 morning workout.

*When to Use Each Kind*

Use whichever kind of time most succinctly and completely handles your time needs. Don't depend on time zone information as a proxy for a location; that's depending on a side effect, which is always brittle. Always store location information separately if it's important.

Examples:

Recording an event: Absolute

Log entries: Absolute

An appointment: Fixed

Your daily schedule: Floating

Deadlines: Usually fixed time, but possibly absolute time.

[lolc]

Interesting to see fixed and floating time differentiated. I didn't really have a name for that last concept.

And fixed time I would call local time. Why call it fixed? Because it's tied to a location?

[kstenerud]

I avoided "local" because the name could technically be claimed by both types: "It's called -local- because it's local to a particular zone" vs "It's called -local- because it's local to my current (local) zone."

So I went with floating vs fixed because it feels less prone to ambiguity. "Fixed" is fixed to a particular zone, and "floating" floats along with me as my current zone changes.

[bloak]

> I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps.

Several people have already replied pointing out that for scheduling events in the future, particularly recurring events, it's practically necessary to refer to time zones.

So I'll just mention the problem of leap seconds, which are announced six months in advance. If a one-second error could cause problems then probably you should use TAI rather than UTC. But you still need UTC for other purposes, so probably you need both and so you need to keep track of whether a particular timestamp is TAI or UTC.

[levosmetalo]

And then your application has to schedule a recurring weekly meeting happening at exactly 9:00 CST, and suddenly, you have to update your DB schema and all code instances everywhere to actually deal with the time zones. And then you realize you'd be better off if you were just using a sane time zone library from the start instead of pretending time zones don't exist.

[WatchDog]

They are different things.

You store your datetimes/instants as UTC, you store your "every day at 9 CST" rule separate from that.

Your rule table might have a column for a cron expression, and a column for the tz database name.

Meanwhile, your table for the meeting records has the time represented as a UTC timestamp.

[phlo]

And to stay with the theme of the article: Chances are, the meeting actually _isn't_ intended to be scheduled for 9am CST, but rather 9am America/Chicago. The key difference being that Chicago only observes CST for half of the year, and most people would probably expect for their recurring meeting to happen at the same local time, regardless of the season.

If the meeting is in _the other_ CST (the Taipei one), there's good news: Taipei doesn't do daylight savings. On the flip side, Chicago attendees might dial in fourteen hours early, so Asia/Taipei is a safer bet, too.

[zokier]

> I feel the standard interchange format for datetimes really should be 64 bit Unix timestamps.

UNIX timestamps are ambiguous.

ISO 8601 is perfectly good interchange format.

[pjungwir]

I agree with this, mostly.

Besides the "meeting time" exception others have mentioned, you should be aware of timezones when grouping records into days/weeks/months/years/etc. The timezone affects where you "cut" the continuum into groups. Does Joe's sale count toward his January quota or February? This has all kinds of interesting questions: do you use the user's time zone? The local office timezone? The HQ timezone? UTC for everything? What if the user moves? Stack Overflow's "fanatic" badge just uses UTC: https://stackoverflow.com/help/badges/83/fanatic

[hyperpape]

Other commenters are right, one article that lays out the case that there are plenty of times what you say isn't right: https://zachholman.com/talk/utc-is-enough-for-everyone-right.

Use UTC everywhere, then display in the user's timezone is a perfectly valid pattern...for specific use cases. Those use cases are very common, but many people over generalize, and assume that it can handle all cases.

[netsharc]

Hmm, your applications don't have user input asking for a time?

[bob1029]

We do have one case where we do have to capture the hour of day for an IT activity. In this situation, we present the UI in the timezone configured by the customer's server and additionally display this timezone information in the UI as reference/confirmation for the user. Once the user submits their input in terms of server-local time, we immediately convert it to UTC for storage in our system. Note that because we present the actual TZ info, this even supports servers that are already configured for UTC. We have no edge cases aside from ensuring our users pay attention to the TZ info.

I still don't understand the arguments about a future date requiring a timezone. UTC can 100% accurately represent a future date or event without any ambiguity. If a user, meeting or other aggregate has a culture/timezone preference, this is a completely separate business fact from the time.

[lolc]

> I still don't understand the arguments about a future date requiring a timezone.

A future event at local time requires a location, because the timezone may yet change at that location. Suppose we meet Nov 1st 2017 in Istanbul and decide to repeat this the year after. We agree to meet again Nov 1st 2018 in Istanbul 10:00 local time. This meeting would have been projected to happen at UTC 8:00, because Turkey was scheduled to switch to UTC+2 on October 30 2018.

However, the government decided to not change the timezone and stay on UTC+3. So our meeting, being scheduled for 10:00 local time, would move from UTC 8:00 to UTC 7:00 at the stroke of a pen. If your software had recorded UTC time, it would be ignorant of this change and consequently it would show the meeting at 11:00 local time. You'd be one hour late.

This change in the tz DB is a little window into the questionable cultural achievement that is local time: https://github.com/eggert/tz/commit/e15ef79a603a2fba89ad8f38...

[shhsshs]

> I still don't understand the arguments about a future date requiring a timezone.

It's not that a future date requires a time zone, you are right that can be 100% represented with a fixed timestamp. But there is the extreme case that time zone rules may change from the time you schedule the event to the time it happens, and in that case your event is now at the wrong time.

Consider the case where you have a weekly meeting at 9:00 AM on Tuesdays in an America/Chicago office. You could surely calculate the next N weeks of meetings and save them as UTC timestamps, taking into account that we shift into daylight savings time at some point, so you end up with a nice list of timestamps at 9:00 local time. But if the time zone rules change at any point (say, Chicago decides not to observe daylight savings time any more), now all of your meetings are an hour off.

If you had saved the meetings in a more verbose but true-to-intent format that properly captures "Every Tuesday at 9:00 AM America/Chicago", then at the time those rules changed you would either automatically have updated meeting timestamps, or some consolidation process could go and update the meeting times.

Even without sweeping changes like that, we still have unscheduled leap seconds, minutes, etc. every once in a while, which will also mess up your timestamps. I'm actually excited to see the day my calendar somehow ends up with a meeting at exactly 9:00:01.

[soco]

The GUI elements should have nothing to do with storing and interchanging timestamps. What you display can query the browser timezone to make it look nice, then send it down converted, over.

[stefan_]

Ding ding ding, we got a winner. No, absolutely do not query the timezone once then "convert" (aka remove) the information. Timezones change all the time.

[user-the-name]

And if the timezone changes, should the meeting you booked at 9 AM now happen at 8 AM?

[soco]

There's a (fresh) extensive comment right above mine which explains the 4 different use cases for dates and the very minimal real need of TZ, let's all read it. Sorry I cannot comment otherwise your arguments because you didn't offer any.

[seszett]

You cannot convert a time string in the future to a timestamp. You must keep it as a string with timezone information until the time actually comes.

[netsharc]

IMO depending on the use case, just the TZ info won't save you. Say I arrange a meeting for 4pm local time (where summer daylight savings time will be active) for July 2022.. and then the city I want to meet in gets invaded by a foreign army and changes its timezone. And cancels summer time. What time is my meeting now?

I guess it needs to be a 4-dimensional coordinate, where 1 axis can slide around...

[seszett]

You should store TZ info in the "Europe/Brussels" form, rather than "CET" or "UTC-1" which aren't easy to use anyway.

If a foreign army invades Belgium and changes its timezone, Europe/Brussels will get updated.