5 ms·

Yes! No more jet-lagged minors twice a year, no more train tickets stamped ~200 years in the future (yes, that has happened to me) and no more confusing server

Yes! No more jet-lagged minors twice a year, no more train tickets stamped ~200 years in the future (yes, that has happened to me) and no more confusing server logs with odd duplicates. Also, contact your local EU parliament member and politely explain why this is good...

ajmurmann 9y ago
Nit: Why isn't the server running in UTC?
- petecooper 9y ago
  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.
- untog 9y ago
  Probably because it's an old system the OP has to deal with but cannot re-engineer from the ground up. At least, that's usually my experience.
- msiebuhr 9y ago
  Some people just don't have a global mindset, I guess.
- wang_li 9y ago
  Why is everyone talking about storing data in a presentation format rather than an unambiguous format? Just because it's a log doesn't mean it's not a type of data that should be stored appropriately.
  - philipov 9y ago
    Because integer (milli/nano)seconds since epoch isn't a human-readable format, and logs need to be read by humans, particularly under stressful conditions.
    - oblio 9y ago
      Furthermore, won't Unix time, the most common format, blow up in 2038?
      - uiri 9y ago
        It will overflow a 32 bit integer around that time. If you are using a 64 bit representation, then you'll be fine.
        ksrm 9y ago
        32 bit signed integer. Unsigned will be fine for a good while yet.
- ogdoad 9y ago
  Picked: Because UTC is hardly 'U', and imposes a rampant heliocentricitism. If anything, it can purport to be at most GTC, which would be good enough for a while longer I suppose.
north_east_dev 9y ago
> Also, contact your local EU parliament member and politely explain why this is good... The constituency I last voted in has 3 MEPs for a population of 900,000... I'd be amazed to ever see them, let alone hear back from them.
- the_mitsuhiko 9y ago
  I doubt that many write to MEPs.

ajmurmann 9y ago

Nit: Why isn't the server running in UTC?

petecooper 9y ago
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.
untog 9y ago
Probably because it's an old system the OP has to deal with but cannot re-engineer from the ground up. At least, that's usually my experience.
msiebuhr 9y ago
Some people just don't have a global mindset, I guess.
wang_li 9y ago
Why is everyone talking about storing data in a presentation format rather than an unambiguous format? Just because it's a log doesn't mean it's not a type of data that should be stored appropriately.
- philipov 9y ago
  Because integer (milli/nano)seconds since epoch isn't a human-readable format, and logs need to be read by humans, particularly under stressful conditions.
  - oblio 9y ago
    Furthermore, won't Unix time, the most common format, blow up in 2038?
    - uiri 9y ago
      It will overflow a 32 bit integer around that time. If you are using a 64 bit representation, then you'll be fine.
      - ksrm 9y ago
        32 bit signed integer. Unsigned will be fine for a good while yet.
ogdoad 9y ago
Picked: Because UTC is hardly 'U', and imposes a rampant heliocentricitism. If anything, it can purport to be at most GTC, which would be good enough for a while longer I suppose.

north_east_dev 9y ago

> Also, contact your local EU parliament member and politely explain why this is good... The constituency I last voted in has 3 MEPs for a population of 900,000... I'd be amazed to ever see them, let alone hear back from them.

the_mitsuhiko 9y ago
I doubt that many write to MEPs.