[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.