Timeline for Should I (still) use UTC for all my servers?
Current License: CC BY-SA 4.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 11, 2023 at 6:50 | comment | added | Patrick Bucher | @ilkkachu Obviously, my predecessor must have had a reason for using UTC. I at least assume that he had one. So I wonder if that reason still might hold true, whatever it was. | |
| Apr 8, 2023 at 0:57 | comment | added | Criggie | I find it helps to configure your desktop's clock app to display LOCAL time and UTC. If you use a wall clock, hang a second one clearly labelled. Or use analogue for local time and digital+24 hour clock for UTC. It just works better for me. | |
| Apr 7, 2023 at 15:50 | comment | added | Hauleth | @PatrickBucher, maybe you should just use a log viewer that would adjust your log timestamps when you view them instead of changing whole machine TZ if that is the issue you have with the log timestamps. | |
| Apr 7, 2023 at 11:31 | comment | added | syck | @fraxinus you are correct, please simply ignore the text in the parentheses. | |
| Apr 7, 2023 at 8:40 | comment | added | Thorbjørn Ravn Andersen | The underlying problem is that timestamps are recorded as strings, not dates, which could be converted according to your current locale. | |
| S Apr 7, 2023 at 8:21 | history | suggested | Solomon Ucko | added tags | |
| Apr 6, 2023 at 21:11 | review | Suggested edits | |||
| S Apr 7, 2023 at 8:21 | |||||
| Apr 6, 2023 at 16:07 | comment | added | fgrieu | If you use CET, then there is a two-hours time interval each year (circa the end of October) such that when seeing an isolated log line form this time interval, you can't determine when it occurred, because two different instants have that horodate. Not coincidentally, things tend to behave during that time period (thus probably but not certainly, that event is at the latest of the two possible UTC times). | |
| Apr 6, 2023 at 15:02 | comment | added | Sidney | If you have log files in UTC couldn't you write a script to open/translate the log files to your preferred timezone? Most logs have the timestamp at the start of the line, just regex it out, adjust to your preferred timezone, and save it as a new readable copy -- Of course keep the original log file in UTC, just make one that works for you to compare to the wall clock if needed. | |
| Apr 6, 2023 at 13:03 | answer | added | gnasher729 | timeline score: 11 | |
| Apr 6, 2023 at 10:27 | comment | added | fraxinus | @roaima this is what I know as well, but syck looks confused. Or they suggest changing the timeserver to timezoned time which is both hard to do and an impressively bad idea. | |
| Apr 6, 2023 at 10:10 | comment | added | Chris Davies | @fraxinus NTP time service is always use UTC | |
| Apr 6, 2023 at 8:50 | comment | added | Wernfried Domscheit | What do you mean by "system's time zone"? Internally Linux uses UTC time anyway, result of date should return times as local time (in my opinion), timestamps in logfiles etc. should be better in UTC. For cronjobs, I think you can discuss which one is better in your environment. | |
| Apr 6, 2023 at 7:59 | comment | added | fraxinus | @syck do timeservers deal with time zones? | |
| Apr 6, 2023 at 6:17 | vote | accept | Patrick Bucher | ||
| Apr 5, 2023 at 17:00 | comment | added | ilkkachu | what do you mean "still"? Is there some reason to assume there would have been more reason for that before, but not now?? | |
| Apr 5, 2023 at 16:42 | review | Close votes | |||
| Apr 10, 2023 at 3:02 | |||||
| Apr 5, 2023 at 16:03 | answer | added | Neil | timeline score: 22 | |
| Apr 5, 2023 at 15:53 | comment | added | syck | I would: (1) set up one of your servers as time server that is queried by the others (time and timezone changes will only have to applied once); (2) read the logs via a perl wrapper that corrects timezone issues (adds or subtract hours); (3) store current time difference to UTC in a file on every server. All servers should live in a homogenous UTC environment; CET is for being easier read by humans. | |
| Apr 5, 2023 at 14:45 | history | became hot network question | |||
| Apr 5, 2023 at 8:03 | comment | added | RonJohn | +1 to CRON_TZ. Our servers are contractually mandated to be UTC, but they "live" in the US east coast. Thus, it's set to America/New_York, as is TZ in .bash_profile. | |
| Apr 5, 2023 at 7:50 | answer | added | Chris Davies | timeline score: 61 | |
| Apr 5, 2023 at 7:00 | answer | added | Marcus Müller | timeline score: 40 | |
| Apr 5, 2023 at 6:53 | comment | added | frostschutz | Sounds like "personal preference" to me. Do it whatever way makes sense to you. Also you can use multiple timezones / per process, by setting TZ (or CRON_TZ). Though that may be even more confusing than a single timezone for everything... | |
| Apr 5, 2023 at 6:53 | comment | added | Jaromanda X | personally, I would switch the the timezone that is most suitable to your requirements - of course, a user ... nevermind comment below mentioned what I was going to say | |
| Apr 5, 2023 at 6:45 | history | asked | Patrick Bucher | CC BY-SA 4.0 |