8 ms·

I'm seeing more people recommending this. Is the main reason to avoid the daylight savings time changes twice a year, or am I missing something else obvious? D

I'm seeing more people recommending this. Is the main reason to avoid the daylight savings time changes twice a year, or am I missing something else obvious? Disclosure: I don't use UTC, I set the server to local time. I'm very open to learning why I'm wrong and how I can improve. Edit #2: thanks, responders – makes perfect sense when you put it that way. Today I learned.

mtmail 9y ago
For logs you avoid having one day with 23 hours and one day with 25 hours per year. You also avoid trouble when running a cronjob at 2:30am, one day it would run twice, another not at all.
lazyant 9y ago
You run servers and dbs in UTC then you translate in your app to local times, this is best practice. Otherwise, problems.
- notyourwork 9y ago
  The question was what problems and why would I want to do this. Saying problems happen isn't helpful.
kuschku 9y ago
If you have multiple servers in different timezones, or devs in different time zones, etc, this can all lead to confusion. It’s generally best if all your servers have one identical environment – time in UTC, language in english – globally, everywhere.
michaelbuckbee 9y ago
It's a sanity thing. You're likely going to hit a spot where you need to compare log entries across systems that may or may not be geographically located in the same place.
nolok 9y ago
Let's say your server is in New York, and you set it to local time, so EST. You store some customer records, customer can see them back and see the time of their record. Now you move to Los Angeles with your server. Do you set your server to EST still, and have a server in a timezone that has nothing to do with anything anymore (and the knowledge of why gets lost as time goes by). Or do you set it as PST ? And now what, do you convert your entire database ? Or do you add special code to "fix" the time is the entry is "earlier than X" ? And how do you then handle displaying the time in the customer's own timezone, when he said +4, did he mean yours (EST) + 4 and then it's not good for PST ? What if you have some servers in New York and some in Los Angeles then ? How do you compare stuff ? UTC is great because it forces you to work in a mindset of "it doesn't matter where the server, the customer or me are, this is the base time, and for everyone I offset it to their respective timezone".
- yetanother1980 9y ago
  I store my data in UTC anyway. BUT why not include the timezone in the timestamp? Then in your example you can change the server's timezone with no disruption...
  - dijit 9y ago
    Because it's extra parsing in a pinch? If you're storing it in a database it'll be stored as a 64bit unsigned int (a-la UNIX Epoch) of seconds since 1970 (in UTC) but if it's text-file logs I agree that it should be UTC, this has been standard ops practice for 20~ years.
  - sametmax 9y ago
    Some programs in your server will use the server clock and don't have a timezone settings.
  - JumpCrisscross 9y ago
    > why not include the timezone in the timestamp? I don't think there is an unambiguous way to represent time zones. Time zones are a creation of law and convention. They change, and have changed, over time.
logfromblammo 9y ago
Set the server to UTC and leave it up to users to choose their own locale settings. You can set the default locale to the local time zone. Time zones are for people, not machines. The machine does not have a sleep schedule or business hours.
gaius 9y ago
I thought this was a no-brainer since the very first distributed systems. Run everything, everywhere in GMT and translate to local time if you have to in a cosmetic layer
sudhirj 9y ago
Local time is very idiosyncratic - the hands of the clock on your wall move forwards, backwards, repeat the same hours, skip hours and dance at the will of your people and politicians. Needless to say, this may cause issues in computers. The only clocks that stay consistent and dependable are the ones in UTC land. So the people mirror the clocks of their local government, but computers mirror the UTC clocks.
- baq 9y ago
  Leap seconds would have a word with you. The only time that's fixed is GPS time, or so I heard.
  - tripzilch 9y ago
    Legend has it there's a secret order of monks that have been going "one mississippi, ..." since 1970. They say it's the only way they can be really sure. But nobody knows how, when or why they came to be 23 minutes off ...
- dragonwriter 9y ago
  > The only clocks that stay consistent and dependable are the ones in UTC land. UTC is closer to “consistent and dependable” than local time, but still has leap second issues. TAI is where you go for consistent and dependable.
- sudhirj 9y ago
  Re leap seconds, smearing seems to have solved that rather effectively. The last leap second was a non event thanks to it.
  - welterde 9y ago
    If people do leap second smearing anyway, I wonder if it were possible to just directly use UT1 instead of UTC (the leapseconds are just there to keep UTC synchronized to UT1 to within one second).
cerved 9y ago
It's not just DST. Timezones change, like leap seconds, in a way that's not computer friendly.

mtmail 9y ago

For logs you avoid having one day with 23 hours and one day with 25 hours per year. You also avoid trouble when running a cronjob at 2:30am, one day it would run twice, another not at all.

lazyant 9y ago

You run servers and dbs in UTC then you translate in your app to local times, this is best practice. Otherwise, problems.

notyourwork 9y ago
The question was what problems and why would I want to do this. Saying problems happen isn't helpful.

kuschku 9y ago

If you have multiple servers in different timezones, or devs in different time zones, etc, this can all lead to confusion. It’s generally best if all your servers have one identical environment – time in UTC, language in english – globally, everywhere.

michaelbuckbee 9y ago

It's a sanity thing. You're likely going to hit a spot where you need to compare log entries across systems that may or may not be geographically located in the same place.

nolok 9y ago

Let's say your server is in New York, and you set it to local time, so EST. You store some customer records, customer can see them back and see the time of their record. Now you move to Los Angeles with your server. Do you set your server to EST still, and have a server in a timezone that has nothing to do with anything anymore (and the knowledge of why gets lost as time goes by). Or do you set it as PST ? And now what, do you convert your entire database ? Or do you add special code to "fix" the time is the entry is "earlier than X" ? And how do you then handle displaying the time in the customer's own timezone, when he said +4, did he mean yours (EST) + 4 and then it's not good for PST ? What if you have some servers in New York and some in Los Angeles then ? How do you compare stuff ? UTC is great because it forces you to work in a mindset of "it doesn't matter where the server, the customer or me are, this is the base time, and for everyone I offset it to their respective timezone".

yetanother1980 9y ago
I store my data in UTC anyway. BUT why not include the timezone in the timestamp? Then in your example you can change the server's timezone with no disruption...
- dijit 9y ago
  Because it's extra parsing in a pinch? If you're storing it in a database it'll be stored as a 64bit unsigned int (a-la UNIX Epoch) of seconds since 1970 (in UTC) but if it's text-file logs I agree that it should be UTC, this has been standard ops practice for 20~ years.
- sametmax 9y ago
  Some programs in your server will use the server clock and don't have a timezone settings.
- JumpCrisscross 9y ago
  > why not include the timezone in the timestamp? I don't think there is an unambiguous way to represent time zones. Time zones are a creation of law and convention. They change, and have changed, over time.

logfromblammo 9y ago

Set the server to UTC and leave it up to users to choose their own locale settings. You can set the default locale to the local time zone. Time zones are for people, not machines. The machine does not have a sleep schedule or business hours.

gaius 9y ago

I thought this was a no-brainer since the very first distributed systems. Run everything, everywhere in GMT and translate to local time if you have to in a cosmetic layer

sudhirj 9y ago

Local time is very idiosyncratic - the hands of the clock on your wall move forwards, backwards, repeat the same hours, skip hours and dance at the will of your people and politicians. Needless to say, this may cause issues in computers. The only clocks that stay consistent and dependable are the ones in UTC land. So the people mirror the clocks of their local government, but computers mirror the UTC clocks.

baq 9y ago
Leap seconds would have a word with you. The only time that's fixed is GPS time, or so I heard.
- tripzilch 9y ago
  Legend has it there's a secret order of monks that have been going "one mississippi, ..." since 1970. They say it's the only way they can be really sure. But nobody knows how, when or why they came to be 23 minutes off ...
dragonwriter 9y ago
> The only clocks that stay consistent and dependable are the ones in UTC land. UTC is closer to “consistent and dependable” than local time, but still has leap second issues. TAI is where you go for consistent and dependable.
sudhirj 9y ago
Re leap seconds, smearing seems to have solved that rather effectively. The last leap second was a non event thanks to it.
- welterde 9y ago
  If people do leap second smearing anyway, I wonder if it were possible to just directly use UT1 instead of UTC (the leapseconds are just there to keep UTC synchronized to UT1 to within one second).

cerved 9y ago

It's not just DST. Timezones change, like leap seconds, in a way that's not computer friendly.