6 ms·

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.

by lstodd 1y ago

somat 1y ago
Doing this at the system level was one of the better ideas to come out of unix.
- yencabulator 1y ago
  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.
p_ing 1y ago
Running UTC as a clock on an end user workstation is about the dumbest thing you can do (unless they reside in UTC).
- dheera 1y ago
  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.
- lstodd 1y ago
  Let's hear why you think this.
  - Terr_ 1y ago
    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?
    - teo_zero 1y ago
      > What problem are you thinking it would solve? Traveling.
      - Terr_ 1y ago
        So instead of your settings sometimes being wrong and easily-fixed with a few clicks, you want them to be almost always wrong? :P Again, I don't understand what pain-point or use-case is motivating this "set your laptop OS to UTC" proposal. ... Well, not unless it's some workaround for flawed software running on that machine, perhaps made by developers that misunderstood the business-domain of time zones.
        teo_zero 1y ago
        > So instead of your settings sometimes being wrong and easily-fixed with a few clicks It can't be easily fixed. Imagine I continuously change the OS's setting to always reflect the local time. Now I read a log of events happened last Tuesday. Was it when I was in Europe or when I was in the US? How should I read those timestamps? Then I compare two timestamps from last spring. They differ a few minutes, but one was before the switch to DST the other was after. Which one happened first? > you want them to be almost always wrong? I think "wrong" is relative, isn't it? > Well, not unless it's some workaround for flawed software Exactly the opposite: there used to be a SO from Redmond that didn't allowed you to set its internal clock to UTC. I think it's been corrected now.
        Terr_ 1y ago
        > Imagine I continuously change the OS's setting to always reflect the local time. Now I read a log of events happened last Tuesday. Those two things are unrelated, how frequently you changed timezone settings should have zero impact on your log... unless it means more "settings changed" entries. Changing your current timezone does not move things that already happened. The event-log entries (A) shall be order-able by actual chronology, excepting relativistic effects, and (B) shall all display under some unified reporting timezone, whether that's hardcoded to be UTC, or the system timezone when exporting/displaying, or a time-zone chosen in an Event Viewer GUI. If either (A) or (B) are false, that means you're dealing with worryingly flawed software from developers who weren't prepared to implement timezone logic. > Now I read a log of events happened last Tuesday. Was it when I was in Europe or when I was in the US? In all cases, your first step is to figure out where those real-world events fall relative to the log entries. It will always be less work if the event-log display timezone happens to match one of the ones for your departure/arrival times. > Then I compare two timestamps from last spring. They differ a few minutes, but one was before the switch to DST the other was after. Which one happened first? Easy: The one that sorts earlier, and if you display logs in UTC they will be visually distinct as well.
- izacus 1y ago
  Thing is... noone resides in UTC at all.
  - benjojo12 1y ago
    Reykjavik lives all year round in UTC
    - gerikson 1y ago
      So does a large part of Western Africa.
    - wasmitnetzen 1y ago
      Places do not lie in UTC, data does. Iceland follows Western European Time (WET), which has no offset to UTC.
- adrian_b 1y ago
  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.
- teo_zero 1y ago
  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).
anonymars 1y ago
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.
- Terr_ 1y ago
  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."
  - s20n 1y ago
    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.
    - deleted 1y ago
      [deleted]
    - WillDaSilva 1y ago
      Timezones are not static, and actually change somewhat frequently. A program that converts any given future time to UTC risks becoming incorrect about when that time is due to political changes that affect the timezone the given future time was in.
    - dqv 1y ago
      > Converting timestamps between time zones is perfectly reversible while there is a loss of information when you convert a value to a new currency. False. This scenario absolutely does happen: 2027-03-08 11:00AM (Local) -> 2027-03-08 2:00PM (UTC) (tzdata version changes) 2027-03-08 10:00AM (Local) <- 2027-03-08 2:00PM (UTC)
- adrian_b 1y ago
  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.
Terr_ 1y ago
> 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.
- adrian_b 1y ago
  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.
  - kaoD 1y ago
    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/ https://tc39.es/proposal-temporal/docs/

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.

by lstodd 1y 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.

somat 1y ago

Doing this at the system level was one of the better ideas to come out of unix.

yencabulator 1y ago
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.

p_ing 1y ago

Running UTC as a clock on an end user workstation is about the dumbest thing you can do (unless they reside in UTC).

dheera 1y ago
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.
lstodd 1y ago
Let's hear why you think this.
- Terr_ 1y ago
  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?
  - teo_zero 1y ago
    > What problem are you thinking it would solve? Traveling.
    - Terr_ 1y ago
      So instead of your settings sometimes being wrong and easily-fixed with a few clicks, you want them to be almost always wrong? :P Again, I don't understand what pain-point or use-case is motivating this "set your laptop OS to UTC" proposal. ... Well, not unless it's some workaround for flawed software running on that machine, perhaps made by developers that misunderstood the business-domain of time zones.
      - teo_zero 1y ago
        > So instead of your settings sometimes being wrong and easily-fixed with a few clicks It can't be easily fixed. Imagine I continuously change the OS's setting to always reflect the local time. Now I read a log of events happened last Tuesday. Was it when I was in Europe or when I was in the US? How should I read those timestamps? Then I compare two timestamps from last spring. They differ a few minutes, but one was before the switch to DST the other was after. Which one happened first? > you want them to be almost always wrong? I think "wrong" is relative, isn't it? > Well, not unless it's some workaround for flawed software Exactly the opposite: there used to be a SO from Redmond that didn't allowed you to set its internal clock to UTC. I think it's been corrected now.
        Terr_ 1y ago
        > Imagine I continuously change the OS's setting to always reflect the local time. Now I read a log of events happened last Tuesday. Those two things are unrelated, how frequently you changed timezone settings should have zero impact on your log... unless it means more "settings changed" entries. Changing your current timezone does not move things that already happened. The event-log entries (A) shall be order-able by actual chronology, excepting relativistic effects, and (B) shall all display under some unified reporting timezone, whether that's hardcoded to be UTC, or the system timezone when exporting/displaying, or a time-zone chosen in an Event Viewer GUI. If either (A) or (B) are false, that means you're dealing with worryingly flawed software from developers who weren't prepared to implement timezone logic. > Now I read a log of events happened last Tuesday. Was it when I was in Europe or when I was in the US? In all cases, your first step is to figure out where those real-world events fall relative to the log entries. It will always be less work if the event-log display timezone happens to match one of the ones for your departure/arrival times. > Then I compare two timestamps from last spring. They differ a few minutes, but one was before the switch to DST the other was after. Which one happened first? Easy: The one that sorts earlier, and if you display logs in UTC they will be visually distinct as well.
izacus 1y ago
Thing is... noone resides in UTC at all.
- benjojo12 1y ago
  Reykjavik lives all year round in UTC
  - gerikson 1y ago
    So does a large part of Western Africa.
  - wasmitnetzen 1y ago
    Places do not lie in UTC, data does. Iceland follows Western European Time (WET), which has no offset to UTC.
adrian_b 1y ago
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.
teo_zero 1y ago
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).

anonymars 1y ago

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.

Terr_ 1y ago
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."
- s20n 1y ago
  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.
  - deleted 1y ago
    [deleted]
  - WillDaSilva 1y ago
    Timezones are not static, and actually change somewhat frequently. A program that converts any given future time to UTC risks becoming incorrect about when that time is due to political changes that affect the timezone the given future time was in.
  - dqv 1y ago
    > Converting timestamps between time zones is perfectly reversible while there is a loss of information when you convert a value to a new currency. False. This scenario absolutely does happen: 2027-03-08 11:00AM (Local) -> 2027-03-08 2:00PM (UTC) (tzdata version changes) 2027-03-08 10:00AM (Local) <- 2027-03-08 2:00PM (UTC)
adrian_b 1y ago
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.

Terr_ 1y ago

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

adrian_b 1y ago
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.
- kaoD 1y ago
  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/ https://tc39.es/proposal-temporal/docs/