No. ALWAYS store user-entered dates in UTC, and simultaneously either (a) save the user's timezone preference or (b) use their system-specified timezone and only do that conversion at the last step when rendering the UI, preferably with client-side timezone functions. Also use client-side timezone functions to provide the server with UTC dates directly.

You'll deal with DST hell on your server otherwise. Countries change their DST and timezone policies from time to time, and you don't want to have to deal with keeping track of that stuff or force upgrading your server for a petty politician/timezone issue. That's the client machine's job.

Saving everything in UTC also makes comparisons, logging, abuse tracking much easier.

Future times record intent, which requires storing a datetime (sans any kind of time zone information) and location. Past times can be stored as a UTC timestamp.

Storing and using a time zone for points in the future is the path of madness. If a user has an event at 2pm six months from now, they almost certainly want that event to be at 2pm no matter what the UTC offset happens to be on that day. This becomes even more obvious for repeating events: an event at 2pm this week will still be at 2pm six months from now, even after DST flips. And even if my government decides to change the time zone my location is in, or decided to opt into/out of DST.

> If a user has an event at 2pm six months from now, they almost certainly want that event to be at 2pm no matter what the UTC offset happens to be on that day

Not necessarily. If the event is a long distance meeting that span multiple timezones, then by definition, the event isn't going to be at 2pm for all consumers of that data.

Location is kind of a proxy for timezone, but it makes more sense to just let the client's OS figure the offset from UTC time than to manually manage timezones in the server yourself.

Similarly, you let the client tell the server what timestamp "2pm two weeks from now" is (letting it consult its OS' timezone database to figure out what that means for the user's chosen geographic location), rather than trying to naively add up the seconds from now to then in the server.

Saving the user's location in your DB to compute offsets on the server is problematic because you can't always get geographic data from the client (e.g. browsers will readily make timezone available to Javascript, but geolocation data might be unobtainable due to permissions/privacy concerns/etc). Also, users may move/travel, so getting geo data from side channels such as sign up forms also could lead to discrepancies.

If you store UTC, you automatically get the result that meeting occurs at the same time for everyone. But you could also get the situation where, depending on timezone and DST changes, that 2:00pm meeting doesn't occur at 2:00pm for any of the participants!

The problem is really far more difficult and interesting than just storing all dates as UTC as a rule.

AFAIK that can only happen if the the government changes the DST policy (or timezone) between the time the event was scheduled and the meeting date. Thankfully, DST policy changes are comparatively rare.

And in actuality, even if the event doesn't happen at 2pm for the person who got affected by the DST policy change, it'll still be scheduled at the "expected" time for everyone else (unless they too get affected by a DST policy change as well).

Also, most OSes are decent enough nowadays to update their timezone/DST databases regularly so that UIs that use UTC will reflect the discrepancy in future time intent soon after the policy change takes effect.

If you convert a future date-time to UTC using the current timezone database you've already lost. If the timezone database changes anytime from that point forward, you cannot correctly convert that UTC date back to local time.

You have no way of knowing, just looking at a UTC date, under what conditions it was converted from local time.

By converting a future date to UTC, you're making the assumption that the timezone information you have for that future date won't change from now until that date passes.

> Thankfully, DST policy changes are comparatively rare.

"Russia switched to permanent DST from 2011 to 2014, but the move proved unpopular...so the country switched permanently back to standard time in 2014... Florida legislature and Washington State Legislature passed bills to enact permanent DST, pending US Congressional approval, and California, Maine, Massachusetts, New Hampshire, and Rhode Island have introduced proposals or commissions to that effect... Under an EU directive, from 2021 twice-yearly adjustment of clocks will cease. Member states will have the option of observing either standard time or summer time all year round." -- Wikipedia

You seem to be missing the forest for the trees. DST policy changes _are_ rare, compared to the millions of times when people schedule multi-timezone meetings, international flights, etc. Bursts of high frequency DST policy changes are so rare that they get articles written about them.

> you cannot correctly convert that UTC date back to local time.

Of course you can. It may not be the same local clock time with most implementations, sure, but it will still correctly point to the same physical time relative to the local times of everywhere else on Earth. It would be physically impossible to retroactively change the time of the meeting to account for the the DST policy change and maintain the same clock time for participants in other timezones, so something's gotta give.

It's also not true that you can't recover the intended time after a DST policy change. Although it's monumentally laborious, it's definitely possible: you can keep track of the historical changes in the timezone database and work backwards from the UTC date and the date of that record change.

> By converting a future date to UTC, you're making the assumption that the timezone information you have for that future date won't change from now until that date passes.

Sort of. The assumption there is that the time delta between now and then is smaller than the delta between a notice of policy change and the time it goes into effect. It is, however, technically an engineering trade-off. The trade-off here is that you can have a far simpler and almost-always correct implementation by taking a tiny risk of a discrepancy between intent and actual local time in the extremely rare occasion that a policy changes without advance notice. Responsible governments will typically give plenty of advance notice so timezone databases can be updated and clients can then correctly calculate future offsets since they will know how to account for the policy change.

You could certainly forego UTC time and make an engineering decision of storing local clock time if your application matches a very strict set of timezone boxing requirements, but in my experience, it's more common that people pick this approach out of ignorance than careful analysis, and in some cases, it gets nasty to support when the requirements change (e.g. as soon as you have a new sales team office on the other side of the country)

Why go through all this just to follow the rule of storing UTC in the database? At what point does it just become the wrong thing to do?

Storing local time and timezone in the database for future dates is easy. It has none of these issues. It produces the correct results that people expect. You can convert to UTC at anytime.

Storing local time is fine if you and your server never ever leave your timezone. You can even get away with it for a long time. If your logic does ever require timezone conversions down the line though, it will most likely surface some nasty problems. And when I say nasty, I mean it in the will-leave-a-battle-scar-that-your-future-graybeard-self-will-warn-younguns-about sense.

The thing with the UTC advice and those who don't listen to it is that people often don't realize that both DST policy changes and factors that increase the number of applicable timezones in a business are rare to begin with. They often think that that storing local time is safe because they never had to truly deal with the complexities of representing physical time.

But DST policy changes are much rarer than factors that fuck up local time based implementations, and issues can be fixed without huge schema changes and downtimes. Plus it's less likely you will actually need to fix them since higher-ups won't be able to grasp the issue, whereas a local time bug fix will often come as a demand from some higher-up suit who flew out of state.

I've said all over this thead to store local time and the associated timezone. You do that and no nasty problems can happen. And you are correctly storing the time that the user intended and not the time it might be converted into.

If you're storing the timezone (and by that I assume you're doing so unambiguously, because offset alone doesn't tell you hemisphere/DST rules, and timezone names are not unique), then you're effectively using UTC, albeit storing it in a non-normalized format.

The flaw in your logic is in assumption that "intended time" is always fixed relative to one user's clock time. For international events, intended time is physical time. If it's a friday and I verbally arrange a meeting with someone in Sao Paulo at 3pm BST the following monday and that translates to 11am PST today for me at San Francisco, but if there's a DST change for me over the weekend, the intended time is still 3pm BST, not 11am PST, because in such cases, the general logical expectation is that whoever is getting a time change is the one who should be on top of it.

In either case, you'd be able to recover "intended time" (for any meaning of the term) 99.9999% of the time regardless of whether you used UTC or local time+timezone. If there was indeed an unlikely event of an unannounced DST policy change, then whether intended time is wrong depends on who's affected. If it's an international meeting and intended time means physical time, then local time+timezone does not capture true intended time. Likewise, if intended time means local time for a single user, UTC will be the wrong one. But as I said, this case is vanishingly unlikely. A lot of code doesn't handle integer overflows correctly because they are unlikely too and the world is still humming along just fine.

> You seem to be missing the forest for the trees. DST policy changes _are_ rare, compared to the millions of times when people schedule multi-timezone meetings, international flights, etc. Bursts of high frequency DST policy changes are so rare that they get articles written about them.

It's not just DST policy changes. If I want to run a report at 10PM every day in my timezone and we store that time as UTC then my report will be running at 11PM after the DST change over, it will start screwing up twice a year. This does not happen when my local time and timezone are stored because the software working with the data can make smarter decisions with more information.

> screwing up

Is it wrong just because the clock time is wrong? Or is the data actually going to get corrupted? In my experience, reports are usually reporting on a period of time, and it doesn't actually matter if the job runs an hour off since you don't want them to be time sensitive in the first place (e.g. you might get noise because some query became very expensive for some reason and delayed a portion of the job by an hour, or the job ran in a data center in a different state, etc). Besides, this isn't really the same class of problems that the "use UTC" advice targets. Crons are a far better tool for daily scheduled jobs. The UTC advice is for systems that communicate dates across multiple machines.

In 2018 there was 9 updates to the Olsson timezone database, it's not as irregular as you'd think. It doesn't always get communicated with notice, and sometimes applies retroactively depending on which government and point in history.

Independent of all that the train still leaves at 2pm local time and I need to be on it.

> Future times record intent, which requires storing a datetime (sans any kind of time zone information) and location.

This assumes particular kind of intent, but not the only kind of intent future times might represent. Datetime + named time zone is often the actual intent (e.g., often for TV schedules), datetime + whatever the then-current legal time is at some particular location is, as you note, also often an intent, but it's not the only possible one. Note also that either of those may not be unique, depending on whether the named zone is offset specific or includes DST shifts, due to DST and other rarer sources of duplicate times in one zone or location , and the intent often is for a unique time, so you may actually need to store even more to capture intent.

Can you clarify? If I've seen an ad for a TV show saying it's going to air at 6 PM CST, I'm going to miss the show if it's actually on at 5 PM CST because the DST law changed or what have you.

If you use the client's timezone preference to store the date and then use the client's timezone preference to recover the date at a future date, you might still mess it up (from the user perspective).

It depends on the user's intent. If they book something at 4:00pm 2 years from now, will that become 5:00pm if the timezone rules change or stay at 4:00pm. I'd argue that for most future-dated items it should stay at 4:00pm. The only way to guarantee that is store the local time.

Storing UTC doesn't relieve you of timezone problems.

Wait, you're using "Countries change their DST and timezone policies from time to time" as an argument for storing UTC in the database?

As far as I'm concerned, this is the only valid argument against UTC. If a user adds an event for e.g. 2pm March 25th 2022 local time, you convert it to UTC, and then later the conversion rules for that day change, you now have a date that's been improperly converted to UTC.

I don't think it's a strong enough reason not to use UTC in the db, given the multitude of issues surrounding other choices, but I do think that it's important to be clear about the pros and cons.

> If your application is future-dating items, like say clients entering appointments in a calendar, this will be very wrong.

Well, the future has problems no matter what you do.

> If a customer enters an appointment 6 months in the future, it will end up at the wrong time due to daylight savings time.

No, becauae that you store UTC doesn't mean that you also convert entries to UTC using the offset on the entry date without looking at the date the time is attached to.

OTOH, no matter what you store, the fact that DST rules and even timezone boundaries can change over time means that you have to store a lot more about the intent than just the time to be certain of being correct for future times. Did you want X time in Y time zone or X time in the legal time applicable to Z venue? The former is often used as a proxy forthe latter on the assumption that tim zones don't change...

You store the offset or you store the users configuration. Use the users config and/or offset to convert it from UTC. There should be a way to account for DST. I’ll look into it when I get a chance.

If the future date was input in EDT or EST you’d know what to do in the future when you convert back to either EDT or EST based on the time of year.

You can do a lot of things but, at some point, you have to ask yourself if the solution is signficantly more complex than storing local time and the timezone.

You also need to be aware that timezones change; even now there are discussions about eliminating daylight saving time in various regions. If you store 4:00pm on Nov 25th and convert that to UTC based on the timezone rules as they exist today, you'll be wrong when you convert them back under different timezone rules. There's just no way to do that cleanly.

There are also things to consider: if the user changes their own timezone (by moving) did they intend the value of that time to change (4:00pm is now 1:00pm because it's a WebEx and they moved East) or did they intend that to remain at 4:00pm (it's when they take their medicine every day).