4 ms·

All of the arguments in this post supporting UTC could be applied to any timezone without daylight saving. If your company is entirely located in California or

by raldi 10y ago

All of the arguments in this post supporting UTC could be applied to any timezone without daylight saving. If your company is entirely located in California or some other Pacific Time location, consider putting your servers on Arizona time. There's no daylight saving, and for most of the year, the server time will match your wristwatch. In the winter, when California is on PST, the servers will only be off by an hour. I find that much more tolerable than the hassles of UTC servers, where you can't instantly translate between server time and wall time in your head, and server midnight rolls over in the middle of the California day, and thus datestamped logfiles don't match up at all with your wall calendar. Edit: If you're going to downvote, please post a comment explaining why, so that readers can learn something.

karma_vaccum123 10y ago
Ugh, daylight savings time and "imperial" measurements are two things I would just order away if I could be granted dictatorial powers for one day.
- deleted 10y ago
  [deleted]
tbarbugli 10y ago
What if Arizona decides to adopt DST?
- waterphone 10y ago
  It's unlikely to. Residents of a state where summer temperatures get well over 100° regularly don't want summer days to be even longer. The few attempts to do so (for no good reason) have always failed spectacularly, and most Arizona residents are very pleased with it the way it is.
  - dragonwriter 10y ago
    DST had no effect on day length. It has an effect on which actual hours of the day are outside of conventional working hours.
    - waterphone 10y ago
      Exactly, and my point still stands. Arizonans want the sun to set sooner after work so they can enjoy a cooler evening and have the hot hours over earlier relative to getting out of work.
- raldi 10y ago
  What if UTC adopts DST? What if the sun explodes?
  - dietrichepp 10y ago
    UTC won't adopt daylight savings, but Arizona might. This is a foreseeable event which you can mitigate against, unlike the sun exploding.
    - raldi 10y ago
      In the extraordinarily unlikely event that both Arizona and Sonora adopt DST, you can just put an entry in your /usr/share/zoneinfo for Fakeville, US, an imaginary town that honors the time that Arizona and Sonora used to.
- Symbiote 10y ago
  You could simply set the TZ variable to a fixed offset: $ TZ='<UTC-7>+7' date -R Sat, 16 Jul 2016 11:04:52 -0700 Or use Sonora in Mexico: $ TZ=:America/Hermosillo date -R Sat, 16 Jul 2016 11:05:39 -0700 Another option is Pitcairn Island, which is -0800 all year. $ TZ=:Pacific/Pitcairn date -R Sat, 16 Jul 2016 10:06:23 -0800 though the standard abbreviation, PST, is probably confusing.
MaulingMonkey 10y ago
> All of the arguments in this post supporting UTC could be applied to any timezone without daylight saving. Not this one: >> I have (in the past), seen servers where the system timezone is set to PST, but the database is set to UTC, causing more crazy bugs, because for 8 hours a day, calling now() in the database has a different date from the application that talks to it.
- raldi 10y ago
  That isn't an argument against non-UTC servers; it's an argument against using different timezones on your servers and applications. If your servers and applications are both on Arizona time, it doesn't manifest itself.
  - MaulingMonkey 10y ago
    It's an argument for a consistent timezone. If you're exposing an API to (or otherwise sharing data with) third parties, they're unlikely to have standardized on your localish timezone, unless they happen to share it. If you're consuming a third party API (or otherwise consuming data from them), they're unlikely to have standardized on your localish timezone, unless they happen to share it. If you live in a disconnected bubble, your localish timezone might be consistent enough. You probably don't live in a disconnected bubble. Your localish timezone is not consistent. It is not "Universal". It is not UTC.
dingaling 10y ago
> I find that much more tolerable than the hassles of UTC servers, where you can't instantly translate between server time and wall time in your head Background: we moved all our pan-US servers ( Windows, Unix, AS/400 and MF ) to UTC back in the early 2000s, instead of following the local TZs. I didn't experience any particular instance when I wanted to convert a server incident to wall-time. Since all events were scheduled in UTC it was a direct look-up between (1) unusual things happening on server and (2) any jobs scheduled at that time. What time it was in the office or in the customer's TZ didn't really matter. The only time we converted to wall-time was internally within teams to determine when our maintenance shifts would start. With globally-outsourced support teams, the server load charts dictated the UTC time to start the work which was communicated to the appropriate teams who performed local conversion for their shifts. Once they were in the office, everything was executed on UTC.
_callcc 10y ago
Most people in this thread don't seem to have experienced how irritating it is to work in UTC. The argument they make is mainly about logging--they basically want to make sure the log line timestamps are in UTC for the sake of avoiding ambiguity. Fine. But when I want to generate a daily report and all the timestamps in the database are in UTC, it's a pain. Measures of time and weight are necessarily conventional so what really matters is consistency.
- joshstrange 10y ago
  Couldn't disagree more, I have done extensive work with timezones and UTC where I work and reporting annoyance is a terrible reason for considering something other than UTC. Your front end (be it a browser, cli, or gui) should be responsible for translating dates from the back end to your prefered TZ. Also you indicate that consistency is what matters, I agree which is why I use UTC. Your are completely skipping over DST and how it can mess up other things.
  - _callcc 10y ago
    No, consistency is what matters. If you can get away with working with localtime then there's no reason to opt for the faux-universality of using UTC instead.

by raldi 10y ago

karma_vaccum123 10y ago

Ugh, daylight savings time and "imperial" measurements are two things I would just order away if I could be granted dictatorial powers for one day.

deleted 10y ago
[deleted]

tbarbugli 10y ago

What if Arizona decides to adopt DST?

waterphone 10y ago
It's unlikely to. Residents of a state where summer temperatures get well over 100° regularly don't want summer days to be even longer. The few attempts to do so (for no good reason) have always failed spectacularly, and most Arizona residents are very pleased with it the way it is.
- dragonwriter 10y ago
  DST had no effect on day length. It has an effect on which actual hours of the day are outside of conventional working hours.
  - waterphone 10y ago
    Exactly, and my point still stands. Arizonans want the sun to set sooner after work so they can enjoy a cooler evening and have the hot hours over earlier relative to getting out of work.
raldi 10y ago
What if UTC adopts DST? What if the sun explodes?
- dietrichepp 10y ago
  UTC won't adopt daylight savings, but Arizona might. This is a foreseeable event which you can mitigate against, unlike the sun exploding.
  - raldi 10y ago
    In the extraordinarily unlikely event that both Arizona and Sonora adopt DST, you can just put an entry in your /usr/share/zoneinfo for Fakeville, US, an imaginary town that honors the time that Arizona and Sonora used to.
Symbiote 10y ago
You could simply set the TZ variable to a fixed offset: $ TZ='<UTC-7>+7' date -R Sat, 16 Jul 2016 11:04:52 -0700 Or use Sonora in Mexico: $ TZ=:America/Hermosillo date -R Sat, 16 Jul 2016 11:05:39 -0700 Another option is Pitcairn Island, which is -0800 all year. $ TZ=:Pacific/Pitcairn date -R Sat, 16 Jul 2016 10:06:23 -0800 though the standard abbreviation, PST, is probably confusing.

MaulingMonkey 10y ago

> All of the arguments in this post supporting UTC could be applied to any timezone without daylight saving. Not this one: >> I have (in the past), seen servers where the system timezone is set to PST, but the database is set to UTC, causing more crazy bugs, because for 8 hours a day, calling now() in the database has a different date from the application that talks to it.

raldi 10y ago
That isn't an argument against non-UTC servers; it's an argument against using different timezones on your servers and applications. If your servers and applications are both on Arizona time, it doesn't manifest itself.
- MaulingMonkey 10y ago
  It's an argument for a consistent timezone. If you're exposing an API to (or otherwise sharing data with) third parties, they're unlikely to have standardized on your localish timezone, unless they happen to share it. If you're consuming a third party API (or otherwise consuming data from them), they're unlikely to have standardized on your localish timezone, unless they happen to share it. If you live in a disconnected bubble, your localish timezone might be consistent enough. You probably don't live in a disconnected bubble. Your localish timezone is not consistent. It is not "Universal". It is not UTC.

dingaling 10y ago

> I find that much more tolerable than the hassles of UTC servers, where you can't instantly translate between server time and wall time in your head Background: we moved all our pan-US servers ( Windows, Unix, AS/400 and MF ) to UTC back in the early 2000s, instead of following the local TZs. I didn't experience any particular instance when I wanted to convert a server incident to wall-time. Since all events were scheduled in UTC it was a direct look-up between (1) unusual things happening on server and (2) any jobs scheduled at that time. What time it was in the office or in the customer's TZ didn't really matter. The only time we converted to wall-time was internally within teams to determine when our maintenance shifts would start. With globally-outsourced support teams, the server load charts dictated the UTC time to start the work which was communicated to the appropriate teams who performed local conversion for their shifts. Once they were in the office, everything was executed on UTC.

_callcc 10y ago

Most people in this thread don't seem to have experienced how irritating it is to work in UTC. The argument they make is mainly about logging--they basically want to make sure the log line timestamps are in UTC for the sake of avoiding ambiguity. Fine. But when I want to generate a daily report and all the timestamps in the database are in UTC, it's a pain. Measures of time and weight are necessarily conventional so what really matters is consistency.

joshstrange 10y ago
Couldn't disagree more, I have done extensive work with timezones and UTC where I work and reporting annoyance is a terrible reason for considering something other than UTC. Your front end (be it a browser, cli, or gui) should be responsible for translating dates from the back end to your prefered TZ. Also you indicate that consistency is what matters, I agree which is why I use UTC. Your are completely skipping over DST and how it can mess up other things.
- _callcc 10y ago
  No, consistency is what matters. If you can get away with working with localtime then there's no reason to opt for the faux-universality of using UTC instead.