Comment by lstodd
3 days ago
if one is serious, one just chooses UTC.
one can play with timezones all they want, but in the end it's a presentation issue.
3 days ago
if one is serious, one just chooses UTC.
one can play with timezones all they want, but in the end it's a presentation issue.
> in the end it's a presentation issue.
Whoah there, no, that's a huge pitfall of sharpened spikes as soon as you deal with events in the future.
If someone proposes an after-work party for "5:30 PM" at the Latverian office in Latverian time, that's not a fixed offset of seconds from now, it's actually a set of triggering conditions.
We can make a decent guess about when those conditions will be satisfied, but don't actually know until it finally happens. At any moment, the administration of Dr. Doom could arbitrarily change the country's clocks. They might skip over that entire hour, or the hour might repeat on that day, or the entire country might cease to exist.
Making a prediction in UTC and storing just that is a very bad idea, because you lost all the original context you need to recalculate a better prediction as things change. Storing the "5PM in Latverian" is how we keep that context.
Here the problem is that past "time" values and future "time" values should be different data types, e.g. "Time" and "FutureTime".
A past time value (e.g. the times of logged events) actually is a time value that is known and it should be stored as a TAI or UTC value and when desired it can be converted to any date/time format for presentation purposes.
In most cases, a future time value is not a known time value yet and it must be stored as a more complex data type, at the minimum including the local time and the time zone, but for more distant future dates preferably also including the exact geographic location, for the eventuality of changes in the time zone laws.
Therefore, both you and the poster to whom you have replied are right, but you are right only when talking about future time values, while the other poster was right only when talking about past time values.
This is not about "future" or "past" dates but (to use Temporal as a common language) whether the date is an Instant or a ZonedDateTime conceptually.
I think that's essentially what you mean, but it's an important distinction. It's use-case based. Making a data type time-based will not simplify, but only complicate things.
[0] https://tc39.es/proposal-temporal/docs/
UTC helps store specific moments in time. Notably it does not solve for "dates" nor recurrence. Many of my hairs have been lost to third parties thinking they've created viable systems simply because they use UTC.
UTC or TAI are the right solution for storing past time values. Any other information is superfluous and it makes things more complicated than they should be.
Future "time" values are typically not time values. Therefore they must be stored using a different more complex data type, which contains all the information that will be necessary in the future to determine the corresponding time value.
Using the same data type to store both past time values and future time values is in most cases a serious programming mistake, which either wastes resources or is likely to cause bugs.
I wouldn’t say local time is superfluous, as it gives context.
If a historic event occurred at 0300 on Feb 15th, there’s a significant amount of information in knowing the local time. Was it 3am in London, when most people would be asleep. Or was it 7pm Friday night In San Francisco when people were on Valentine's dates, or was it 3pm on Saturday afternoon when people were having a bbq.
If you were to write “the accident occurred at 0300 UTC” then that would imply something very different depending on what the local time was at the time.
How about “the shop opened at 9am every day, without fail”.
Far more useful than “the shop opened at 1600UTC for half the year and 1700UTC for the other half”
2 replies →
I disagree. A stored value that was a future time value yesterday could become a past time value tomorrow. Keeping up with the invariant adds complexity because stored data would have to be migrated all the time.
That added complexity can be much worse than using zoned values for everything.
3 replies →
It's a similar painful insanity as: "Other currencies? Just convert them to US dollars on save, and store that number in the database, nice and easy, no problems."
This is a false analogy. Currencies are volatile whereas timezones are static and rule based.
Converting timestamps between time zones is perfectly reversible while there is a loss of information when you convert a value to a new currency.
3 replies →
Running UTC as a clock on an end user workstation is about the dumbest thing you can do (unless they reside in UTC).
I must be the dumbest person in the world, then, because that's exactly what I've been doing on all my computers for 20 years (and I don't reside in Iceland).
Let's hear why you think this.
Not parent poster, but: It creates annoyance and frustration for the end user, it creates new sources of error (especially when the end-user has to do time-conversions) and provides no actual benefits in terms of system correctness.
What problem are you thinking it would solve?
5 replies →
I do this on all my workstations, phones, wall clocks, Google calendar, and everything. After a lot of frustration I found it the lesser of evils to just think in UTC regardless of where I am in the world, and convert for local people on the fly.
Thing is... noone resides in UTC at all.
Reykjavik lives all year round in UTC
2 replies →
I have set my clock on UTC on all my workstations, desktops and laptops for many decades. This has been particularly convenient on the laptops used in business trips.
For many years, when I still had some other clocks besides those included in computers or mobile phones, e.g. wall clocks or wrist watches, those were also set in UTC, thus with no change between winter and DST.
I prefer to keep in mind the current offset of my local time from UTC, and also the offsets of a couple of places where people with whom I communicate frequently are located, and to add those offsets mentally to the displayed UTC time when that happens to be necessary in order to synchronize to some external event, like a meeting or the opening hours of some place. I schedule my own activities, e.g. eating or sleeping, in UTC.
This habit was triggered decades ago by the fact that I found much more annoying the hour change of all clocks to/from DST than changing in my mind the current offset of the local time from UTC, and also by the fact that the local time does not correspond with the solar time anyway, because I an not located on the center of the time zone, so if I want to know when it is noon, I have to also keep in mind the offset of the solar time from local time, which changes when DST applies. At least with UTC, that offset remains constant.
I do not consider myself dumb :-)
On the contrary, I consider that the legal time is designed for people who are so dumb that they cannot remember that during summer they should wake up and go to work earlier than in winter, the same as their ancestors did for many millennia. To be fair, their ancestors did not use a clock for this, but they woke up depending on the rising sun, which took care of this automatically.
Doing this at the system level was one of the better ideas to come out of unix.
In an operating system especially good for multi-user remote access, why would you assume all your users are in the same timezone?
Timezone is very much a user interface issue.