3 ms·

There are two problems here. In my experience most people, including most developers but perhaps excluding many HN readers, don't understand what the timezone

There are two problems here. In my experience most people, including most developers but perhaps excluding many HN readers, don't understand what the timezone setting does. The time on all contemporary computers is always Unix Epoch Time, which is close to (but not exactly) UTC. Setting your timezone doesn't actually change anything about how time works on the computer. It just changes how time is printed. That's it. So the second problem is that our text-based server world, for all its benefits, doesn't cope well with per-user parameters. I mean ... timezone support on Unix is basically buggy. It doesn't matter what TZ I set in my .profile, nevertheless the timezone of logs is in whatever TZ the server is running in. That's pretty stupid. And even simple calculations like "how many seconds elapsed between this log entry and this one" - which is really common - are very difficult, regardless of the TZ setting. In my own personal perfect world, all logs would be printed in the first column of log files using the epoch time in seconds, and we'd have a command which would convert from the epoch time to the local timezone. So we could do something like: tail -f /var/log/messages | grep 'panic' | timestamp ...in which case I would be able to choose the timezone and format of the timestamps to meet the needs of the job i was doing. So for me, this whole argument over UTC is dumb. It doesn't matter what timezone the system is set to; any zone can be "default". The real problem is that different users have different time formatting requirements, and to date we haven't had tools which deal with that properly. (even logging all timestamps consistently in ISO format would be a big step up...)

jasonjayr 6y ago
You may already know this, but runit's svlogd[1], and djb's daemontool's multilog[2] prefix log lines with tai64[3] timestamps [1] http://smarden.org/runit/svlogd.8.html http://smarden.org/runit/svlogd.8.html [2] https://cr.yp.to/daemontools/multilog.html https://cr.yp.to/daemontools/multilog.html [3] https://cr.yp.to/libtai/tai64.html https://cr.yp.to/libtai/tai64.html
globular-toast 6y ago
There are major pitfalls with using local time, unfortunately. The big one is printing timestamps without the time zone which gives you ambiguous timestamps around the daylight savings time switch. But it's absolutely fine to record timestamps in local time as long as you record the time zone too. You can even randomly switch your time zone throughout the day if you want. Doesn't matter. Your theoretical tool would still work as long as a standard format like ISO8601 is used (also unambiguous wrt leap seconds, unlike Unix). I think the insistence on UTC is a case of "a little knowledge". What happens is some developer somewhere has to learn the hard way about time zones. Now he could either learn about the problem in depth or he finds the shortcut solution: just use UTC. He's now unlikely to ever get bitten again, but he never really learnt what the problem was. He now tells other developers to use UTC and many will blindly follow. In that way it's a bit like the whole insistence on spaces over tabs. Another instance of "a little knowledge" and losing the power of the tab character as a result.
- fpoling 6y ago
  For me the biggest plus of UTC is that the values do not jump back in time in spring during the switch to day light saving times. Surely there are tools that allow to compare/sort time properly as long as there is TZ in the date, but it is easy to forget to use them especially under the pressure. Then those quick-and-dirty scripts ends up as a permanent utility in production, then on the first of April (or the first of March depending on the country) one spends a lot of time trying to understand why the log merge script fails for the previous months. I really prefer to avoid a chance of that in the first place. Now, as Europe got some sanity and will abandon time shifts the next year, local time as long as as it comes with time zone will be OK. But out of habit I guess I will continue to configure servers to use UTC.
  - globular-toast 6y ago
    The thing is, time itself never jumps back. If you correctly encode your timestamps then you will never experience a discontinuity even if you use a local time zone. In the UK on the 29th March 2020 the time was 00:59:59 GMT and one second later it was 02:00:00 BST. There is no discontinuity there. 02:00:00 BST is 01:00:00 GMT. The mistake is to think the time zone is not part of the value. A "naïve" datetime (as the Python standard library calls it) is simply an incorrect way to store a timestamp. Unfortunately it is Unix time that has a real discontinuity. This happens around leap seconds when Unix time will jump backwards or forwards by a whole number of seconds. This is actually the fault of UTC, though. Leap seconds are an abomination. Unix had the right idea all along which is to just count a number of seconds since an epoch and not worry about the movements of the solar system.
JNRowe 6y ago
> In my own personal perfect world, all logs would be printed in the first column of log files using the epoch time in seconds, and we'd have a command which would convert from the epoch time to the local timezone. For a small number of input formats `ts` from Joey Hess' moreutils¹ can do this. Its `-r` option pulls dates out of its input and reformats them, either as a relative timestamp by default(33m57s ago) or a user-specified format if given. Your example becomes `tail | grep | ts -r %FT%T` or something like that. It supports syslog format, a subset of ISO-8601, and a few others. It doesn't support epoch in seconds though, but Joey is nice to interact with if you were to offer a patch. --- This, among other reasons, is why I like all my logging going through systemd's journal nowadays. With journalctl you have a good choice of output options for date formatting or dumping as JSON if you want more. 1. https://joeyh.name/code/moreutils/ https://joeyh.name/code/moreutils/
ericye16 6y ago
>The time on all contemporary computers is always Unix Epoch Time, which is close to (but not exactly) UTC. I think Windows computers set the hardware clock to local time by default, actually.
- rzzzt 6y ago
  There is a way to switch the behavior in either systems, although each comes with its own caveat: https://www.howtogeek.com/323390/how-to-fix-windows-and-linux-showing-different-times-when-dual-booting/ https://www.howtogeek.com/323390/how-to-fix-windows-and-linu...
- TeMPOraL 6y ago
  There must be. I dual-boot between Ubuntu and Windows 10, and whenever I boot up Windows, the clock is behind one or two hours (DST-depending), until it re-syncs itself from the Internet after a while. Ubuntu seems immune, though. So either Ubuntu is smarter about reading the hardware clock, or Windows side writes to the clock differently than it reads from it.
  - kasabali 6y ago
    You need to configure Windows for using UTC when it's dual booting with Linux.
- cmurf 6y ago
  Last time I checked three years ago, the UEFI spec states that the hardware clock (rtc) is set to "current local time". UEFI runtime service's GetTime() includes TimeZone value in minutes offset from UTC, and a Daylight bitmask. Windows, Linux, macOS, all set the timezone value to 0x07FF which is defined as EFI_UNSPECIFIED_TIMEZONE which is to be treated as local time (but without a timezone). In effect, it's the same mess as BIOS. It shows how specs can just be thwarted.
- doctor_eval 6y ago
  I haven't played with Windows since the 90s and just assumed that would have been fixed by now! It seems really silly to set the RTC to local time. Especially given that most devices are mobile these days. Put it to sleep in Melbourne and it wakes up in Singapore...
kstenerud 6y ago
Time is so often done wrong because we're using a bare number to represent time, and then just assuming what that number actually means. It's like the bad old days of text, when you'd get a "string", but you'd have no idea of what encoding it used, so everyone would just assume something. We solved that by settling on UTF-8 for everything - which is fine - but we can't do the same for time, because time zones aren't going away. It's gotten so bad that I've made binary [1] and text [2] formats that handle all cases and have sane defaults (yes, even ISO8601 gets it wrong). A time value without accompanying time zone data is just a bug waiting to happen. Once you add unambiguous timezone information to the time structure, getting correct time information every time is just a matter of making conversion libraries for language X. No more guesswork, no more bugs. [1] https://github.com/kstenerud/compact-time/blob/master/compact-time-specification.md https://github.com/kstenerud/compact-time/blob/master/compac... [2] https://github.com/kstenerud/concise-encoding/blob/master/cte-specification.md#temporal-types https://github.com/kstenerud/concise-encoding/blob/master/ct...
- unilynx 6y ago
  What (defaults) in ISO8601 do you consider wrong?
  - kstenerud 6y ago
    Time zone designators can only be represented as value offsets from UTC, which means that it can't refer to an actual location. Time zones change for political reasons all the time, so using ISO8601 for future events becomes buggy. If Germany changes their policy on Daylight Savings, ISO8601 times such as 2021-08-02T09:00:00+0200 will have a 50% chance of suddenly becoming wrong (because they no longer refer to Berlin time). Another problem with ISO8601 is that omitting the time zone info implies floating time rather than UTC time, and this causes no end of bugs in all implementations. When I finally gave up on it, I came up with the following alternative: Time zone data omitted (implies UTC): 2019-01-23/14:08:51.941245 = January 23, 2019, at 14:08:51 and 941245 microseconds, UTC Area/location based timezone: 1985-10-26/01:20:01.105/America/Los_Angeles = October 26, 1985, at 1:20:01 and 105 milliseconds, Los Angeles time Latitude/longitude based timezone: 5192-11-01/03:00:00/48.86/2.36 = November 1st, 5192, at 3:00:00, at whatever is in the place of Paris at that time
deleted 6y ago
[deleted]
jorams 6y ago
> The time on all contemporary computers is always Unix Epoch Time, which is close to (but not exactly) UTC. Setting your timezone doesn't actually change anything about how time works on the computer. It just changes how time is printed. That's it. Sure, but the only thing users normally see is that printed representation. What's the actual problem you see here? > I mean ... timezone support on Unix is basically buggy. It doesn't matter what TZ I set in my .profile, nevertheless the timezone of logs is in whatever TZ the server is running in. I don't see what's buggy there. If you set a TZ in your .profile, logs produced by processes within the context of that .profile will be in your desired timezone. Processes outside that context look at the system timezone, configured using /etc/localtime. The UTC system time crowd basically just wants all logs (that don't explicitly specify further) to be in a standard timezone that does not move, so that it can be reasoned about without a lot of context. Your perfect world with an epoch time in the first column does exactly that, with the downside of not meaning anything to a human without the timestamp-conversion command. I agree we need better tools to deal with timestamps after the fact.
- doctor_eval 6y ago
  The "bug" -- it's a strawman bug, actually im gonna go with strawbug :) -- is that TZ is supposed to specify what timezone I want to see times written in, and yet when I look at logs the time is not in the timezone I've chosen. So my ideal would be to be able to set TZ and see logs in TZ time. My ideal, to use epoch time instead of local time in logs, is because in a large number of cases I'm more interested in the relative time of log entries than the absolute time. Computing relative time (seconds intervals) between log entries is error prone. I suppose in a sense I'm in both the UTC and non-UTC camp. On reflection, I agree that server logs should be in UTC. I just don't think I should have to read them in UTC or personally operate in UTC. The ts tool mentioned above sounds perfect, and I'm gonna start playing with it...
snvzz 6y ago
>In my experience most people, including most developers but perhaps excluding many HN readers, don't understand what the timezone setting does. The time on all contemporary computers is always Unix Epoch Time, which is close to (but not exactly) UTC. Setting your timezone doesn't actually change anything about how time works on the computer. It just changes how time is printed. That's it. This applies to e.g. Linux. But the RTC in your computer might store localtime. I do recommend using UTC there no matter what. If dual-booting windows, this needs a little extra work[0]. [0]: https://wiki.archlinux.org/index.php/System_time#UTC_in_Windows https://wiki.archlinux.org/index.php/System_time#UTC_in_Wind...
sankao 6y ago
I use vim to browse most logs and have a cheap workaround: a one-liner function with keyboard binding to print the word under cursor converted to local time.

jasonjayr 6y ago

You may already know this, but runit's svlogd[1], and djb's daemontool's multilog[2] prefix log lines with tai64[3] timestamps [1] http://smarden.org/runit/svlogd.8.html http://smarden.org/runit/svlogd.8.html [2] https://cr.yp.to/daemontools/multilog.html https://cr.yp.to/daemontools/multilog.html [3] https://cr.yp.to/libtai/tai64.html https://cr.yp.to/libtai/tai64.html

globular-toast 6y ago

There are major pitfalls with using local time, unfortunately. The big one is printing timestamps without the time zone which gives you ambiguous timestamps around the daylight savings time switch. But it's absolutely fine to record timestamps in local time as long as you record the time zone too. You can even randomly switch your time zone throughout the day if you want. Doesn't matter. Your theoretical tool would still work as long as a standard format like ISO8601 is used (also unambiguous wrt leap seconds, unlike Unix). I think the insistence on UTC is a case of "a little knowledge". What happens is some developer somewhere has to learn the hard way about time zones. Now he could either learn about the problem in depth or he finds the shortcut solution: just use UTC. He's now unlikely to ever get bitten again, but he never really learnt what the problem was. He now tells other developers to use UTC and many will blindly follow. In that way it's a bit like the whole insistence on spaces over tabs. Another instance of "a little knowledge" and losing the power of the tab character as a result.

fpoling 6y ago
For me the biggest plus of UTC is that the values do not jump back in time in spring during the switch to day light saving times. Surely there are tools that allow to compare/sort time properly as long as there is TZ in the date, but it is easy to forget to use them especially under the pressure. Then those quick-and-dirty scripts ends up as a permanent utility in production, then on the first of April (or the first of March depending on the country) one spends a lot of time trying to understand why the log merge script fails for the previous months. I really prefer to avoid a chance of that in the first place. Now, as Europe got some sanity and will abandon time shifts the next year, local time as long as as it comes with time zone will be OK. But out of habit I guess I will continue to configure servers to use UTC.
- globular-toast 6y ago
  The thing is, time itself never jumps back. If you correctly encode your timestamps then you will never experience a discontinuity even if you use a local time zone. In the UK on the 29th March 2020 the time was 00:59:59 GMT and one second later it was 02:00:00 BST. There is no discontinuity there. 02:00:00 BST is 01:00:00 GMT. The mistake is to think the time zone is not part of the value. A "naïve" datetime (as the Python standard library calls it) is simply an incorrect way to store a timestamp. Unfortunately it is Unix time that has a real discontinuity. This happens around leap seconds when Unix time will jump backwards or forwards by a whole number of seconds. This is actually the fault of UTC, though. Leap seconds are an abomination. Unix had the right idea all along which is to just count a number of seconds since an epoch and not worry about the movements of the solar system.

JNRowe 6y ago

> In my own personal perfect world, all logs would be printed in the first column of log files using the epoch time in seconds, and we'd have a command which would convert from the epoch time to the local timezone. For a small number of input formats `ts` from Joey Hess' moreutils¹ can do this. Its `-r` option pulls dates out of its input and reformats them, either as a relative timestamp by default(33m57s ago) or a user-specified format if given. Your example becomes `tail | grep | ts -r %FT%T` or something like that. It supports syslog format, a subset of ISO-8601, and a few others. It doesn't support epoch in seconds though, but Joey is nice to interact with if you were to offer a patch. --- This, among other reasons, is why I like all my logging going through systemd's journal nowadays. With journalctl you have a good choice of output options for date formatting or dumping as JSON if you want more. 1. https://joeyh.name/code/moreutils/ https://joeyh.name/code/moreutils/

ericye16 6y ago

>The time on all contemporary computers is always Unix Epoch Time, which is close to (but not exactly) UTC. I think Windows computers set the hardware clock to local time by default, actually.

rzzzt 6y ago
There is a way to switch the behavior in either systems, although each comes with its own caveat: https://www.howtogeek.com/323390/how-to-fix-windows-and-linux-showing-different-times-when-dual-booting/ https://www.howtogeek.com/323390/how-to-fix-windows-and-linu...
TeMPOraL 6y ago
There must be. I dual-boot between Ubuntu and Windows 10, and whenever I boot up Windows, the clock is behind one or two hours (DST-depending), until it re-syncs itself from the Internet after a while. Ubuntu seems immune, though. So either Ubuntu is smarter about reading the hardware clock, or Windows side writes to the clock differently than it reads from it.
- kasabali 6y ago
  You need to configure Windows for using UTC when it's dual booting with Linux.
cmurf 6y ago
Last time I checked three years ago, the UEFI spec states that the hardware clock (rtc) is set to "current local time". UEFI runtime service's GetTime() includes TimeZone value in minutes offset from UTC, and a Daylight bitmask. Windows, Linux, macOS, all set the timezone value to 0x07FF which is defined as EFI_UNSPECIFIED_TIMEZONE which is to be treated as local time (but without a timezone). In effect, it's the same mess as BIOS. It shows how specs can just be thwarted.
doctor_eval 6y ago
I haven't played with Windows since the 90s and just assumed that would have been fixed by now! It seems really silly to set the RTC to local time. Especially given that most devices are mobile these days. Put it to sleep in Melbourne and it wakes up in Singapore...

kstenerud 6y ago

Time is so often done wrong because we're using a bare number to represent time, and then just assuming what that number actually means. It's like the bad old days of text, when you'd get a "string", but you'd have no idea of what encoding it used, so everyone would just assume something. We solved that by settling on UTF-8 for everything - which is fine - but we can't do the same for time, because time zones aren't going away. It's gotten so bad that I've made binary [1] and text [2] formats that handle all cases and have sane defaults (yes, even ISO8601 gets it wrong). A time value without accompanying time zone data is just a bug waiting to happen. Once you add unambiguous timezone information to the time structure, getting correct time information every time is just a matter of making conversion libraries for language X. No more guesswork, no more bugs. [1] https://github.com/kstenerud/compact-time/blob/master/compact-time-specification.md https://github.com/kstenerud/compact-time/blob/master/compac... [2] https://github.com/kstenerud/concise-encoding/blob/master/cte-specification.md#temporal-types https://github.com/kstenerud/concise-encoding/blob/master/ct...

unilynx 6y ago
What (defaults) in ISO8601 do you consider wrong?
- kstenerud 6y ago
  Time zone designators can only be represented as value offsets from UTC, which means that it can't refer to an actual location. Time zones change for political reasons all the time, so using ISO8601 for future events becomes buggy. If Germany changes their policy on Daylight Savings, ISO8601 times such as 2021-08-02T09:00:00+0200 will have a 50% chance of suddenly becoming wrong (because they no longer refer to Berlin time). Another problem with ISO8601 is that omitting the time zone info implies floating time rather than UTC time, and this causes no end of bugs in all implementations. When I finally gave up on it, I came up with the following alternative: Time zone data omitted (implies UTC): 2019-01-23/14:08:51.941245 = January 23, 2019, at 14:08:51 and 941245 microseconds, UTC Area/location based timezone: 1985-10-26/01:20:01.105/America/Los_Angeles = October 26, 1985, at 1:20:01 and 105 milliseconds, Los Angeles time Latitude/longitude based timezone: 5192-11-01/03:00:00/48.86/2.36 = November 1st, 5192, at 3:00:00, at whatever is in the place of Paris at that time

deleted 6y ago

[deleted]

jorams 6y ago

> The time on all contemporary computers is always Unix Epoch Time, which is close to (but not exactly) UTC. Setting your timezone doesn't actually change anything about how time works on the computer. It just changes how time is printed. That's it. Sure, but the only thing users normally see is that printed representation. What's the actual problem you see here? > I mean ... timezone support on Unix is basically buggy. It doesn't matter what TZ I set in my .profile, nevertheless the timezone of logs is in whatever TZ the server is running in. I don't see what's buggy there. If you set a TZ in your .profile, logs produced by processes within the context of that .profile will be in your desired timezone. Processes outside that context look at the system timezone, configured using /etc/localtime. The UTC system time crowd basically just wants all logs (that don't explicitly specify further) to be in a standard timezone that does not move, so that it can be reasoned about without a lot of context. Your perfect world with an epoch time in the first column does exactly that, with the downside of not meaning anything to a human without the timestamp-conversion command. I agree we need better tools to deal with timestamps after the fact.

doctor_eval 6y ago
The "bug" -- it's a strawman bug, actually im gonna go with strawbug :) -- is that TZ is supposed to specify what timezone I want to see times written in, and yet when I look at logs the time is not in the timezone I've chosen. So my ideal would be to be able to set TZ and see logs in TZ time. My ideal, to use epoch time instead of local time in logs, is because in a large number of cases I'm more interested in the relative time of log entries than the absolute time. Computing relative time (seconds intervals) between log entries is error prone. I suppose in a sense I'm in both the UTC and non-UTC camp. On reflection, I agree that server logs should be in UTC. I just don't think I should have to read them in UTC or personally operate in UTC. The ts tool mentioned above sounds perfect, and I'm gonna start playing with it...

snvzz 6y ago

>In my experience most people, including most developers but perhaps excluding many HN readers, don't understand what the timezone setting does. The time on all contemporary computers is always Unix Epoch Time, which is close to (but not exactly) UTC. Setting your timezone doesn't actually change anything about how time works on the computer. It just changes how time is printed. That's it. This applies to e.g. Linux. But the RTC in your computer might store localtime. I do recommend using UTC there no matter what. If dual-booting windows, this needs a little extra work[0]. [0]: https://wiki.archlinux.org/index.php/System_time#UTC_in_Windows https://wiki.archlinux.org/index.php/System_time#UTC_in_Wind...

sankao 6y ago

I use vim to browse most logs and have a cheap workaround: a one-liner function with keyboard binding to print the word under cursor converted to local time.