4 ms·

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 the

by 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.
  - tzahola 9y ago
    There is an unambiguous way to represent time zones: UTC±hh:mm
    - deleted 9y ago
      [deleted]
    - BerislavLopac 9y ago
      To be pedantic, that's the unambiguous way to represent the UTC offset, not timezones. Different timezones can have the same offset at some moments, but not at others.
      - tzahola 9y ago
        GGP probably meant including the UTC offsets in the timestamps, not timezone names like "Europe/Berlin" or whatever.
        icebraining 9y ago
        Right, but the time zone might not have the same offset in the future, they're not interchangeable.
  - toast0 9y ago
    Events in the past are easy: all you really need is UTC time, but if you store local time and the offset from UTC (and optionally the tzdata timezone name) that works too. For dates in the future, you need to store local time, the timezone name, and the calculated offset for that time. When the database changes, you need to check if the offset changes, and if so, think hard about what that means. Also, some future events are more appropriately scheduled for local time wherever the person happens to be, which is tricky too.
  - petre 9y ago
    Yes there is. It's called ISO 8601. https://en.m.wikipedia.org/wiki/ISO_8601 https://en.m.wikipedia.org/wiki/ISO_8601
- dschuler 9y ago
  Totally agree! I've run into this problem quite a bit, and I think storing the timezone or offset along with a UTC timestamp is the solution. In particular, I want to be able to: 1. Know when a globally ordered even happens. Using UTC or local time with offsets satisfies this requirement. 2. Know when an event occurred in local time, for example movie show times (I can't know what time to print on the ticket without getting the theater's time zone when passed in UTC). UTC does not solve this problem, but local time with offsets works. Example of when I wrote this comment: $ date -u +"%Y-%m-%dT%H:%M:%SZ" 2018-02-08T16:17:48Z $ date +%FT%T%z 2018-02-08T08:17:48-0800 Both formats are ISO8601 compatible. Finally, many client-side requests for dates should be in local wall time without an offset or UTC. Of course this is application dependent, but I've seen this go wrong a few times. Please share other ideas/suggestions if you have them.
- tome 9y ago
  Because then it's denormalized and it's failing to separate concerns. It's storing both the time something happened and the thing strip of longitude it was nominally deemed to have taken place in.
  - dllthomas 9y ago
    A timezone is a political boundary, not "a thin strip of longitude" (unfortunately)

by nolok 9y ago

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.
- tzahola 9y ago
  There is an unambiguous way to represent time zones: UTC±hh:mm
  - deleted 9y ago
    [deleted]
  - BerislavLopac 9y ago
    To be pedantic, that's the unambiguous way to represent the UTC offset, not timezones. Different timezones can have the same offset at some moments, but not at others.
    - tzahola 9y ago
      GGP probably meant including the UTC offsets in the timestamps, not timezone names like "Europe/Berlin" or whatever.
      - icebraining 9y ago
        Right, but the time zone might not have the same offset in the future, they're not interchangeable.
- toast0 9y ago
  Events in the past are easy: all you really need is UTC time, but if you store local time and the offset from UTC (and optionally the tzdata timezone name) that works too. For dates in the future, you need to store local time, the timezone name, and the calculated offset for that time. When the database changes, you need to check if the offset changes, and if so, think hard about what that means. Also, some future events are more appropriately scheduled for local time wherever the person happens to be, which is tricky too.
- petre 9y ago
  Yes there is. It's called ISO 8601. https://en.m.wikipedia.org/wiki/ISO_8601 https://en.m.wikipedia.org/wiki/ISO_8601
dschuler 9y ago
Totally agree! I've run into this problem quite a bit, and I think storing the timezone or offset along with a UTC timestamp is the solution. In particular, I want to be able to: 1. Know when a globally ordered even happens. Using UTC or local time with offsets satisfies this requirement. 2. Know when an event occurred in local time, for example movie show times (I can't know what time to print on the ticket without getting the theater's time zone when passed in UTC). UTC does not solve this problem, but local time with offsets works. Example of when I wrote this comment: $ date -u +"%Y-%m-%dT%H:%M:%SZ" 2018-02-08T16:17:48Z $ date +%FT%T%z 2018-02-08T08:17:48-0800 Both formats are ISO8601 compatible. Finally, many client-side requests for dates should be in local wall time without an offset or UTC. Of course this is application dependent, but I've seen this go wrong a few times. Please share other ideas/suggestions if you have them.
tome 9y ago
Because then it's denormalized and it's failing to separate concerns. It's storing both the time something happened and the thing strip of longitude it was nominally deemed to have taken place in.
- dllthomas 9y ago
  A timezone is a political boundary, not "a thin strip of longitude" (unfortunately)