> What problem are you thinking it would solve?

Traveling.

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 2 days ago | parent [-]

> 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_ 2 days ago | parent [-]

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

	▲	teo_zero 2 days ago \| parent [-]
		I think we agree without understanding each other. It must be possible to sort all system events in an "absolute time line". To do so, the system must know in every moment at what point of this "absolute time line" we are, so that it can stamp the event with such absolute time marker. Now, we can make it coincide with any known TZ, but once set, we must not change it. I set it to UTC; you might prefer your home TZ, if you have a place you call "home". But then don't change it when you travel or when switching DST on and off! Of course you can still change the TZ of the time that's displayed to you (so that it's synchronized with the local church's bells, for example, which is convenient and might avoid you a lot of misunderstanding with your local friends), but not the TZ the OS uses for itself. I find that any choice of home TZ would be arbitrary, so UTC is the best choice.