4 ms·

I bet you already know this but for the reader: the solution is to not think of times occurring with an offset but to rely on the IANA timezone database to figu

I bet you already know this but for the reader: the solution is to not think of times occurring with an offset but to rely on the IANA timezone database to figure out what a timezone means at a particular UTC time: https://www.iana.org/time-zones https://www.iana.org/time-zones

heavenlyblue 8y ago
A question to both parent of this and this specifically. How would you deal with the current EU situation? They have recently voted to stop yearly transitions to summer time. But there must still be a timezone assigned to an event. Are you assigning timezones (in the certificates themselves) as the timezones of a particular geographic location,, rather than as time offsets?
- deleted 8y ago
  [deleted]
- BillinghamJ 8y ago
  On the certificates, we'd state e.g. "this policy runs from 27th March 2019 at 16:52:12 (GMT) to 3rd April 2019 at 17:52:12 (BST)" for a 168-hour (~7 day) policy. Logically, we think of it as the "wall clock" time, plus the location ("Europe/London" - we don't operate outside the UK yet), plus the local zone (BST/GMT) to handle ambiguity when clocks go back. Practically, right now the start/end date-times are stored using a Postgres timestamp with no timezone. As we've never issued an individual policy of more than 28 days' duration or more than 7 days in advance, we've never actually had to deal with any situation where the point-in-time is no longer correct. And this case is not likely to happen without a decent amount of notice. We're very much in favour of abolishing seasonal transitions though - causes lots of confusion.
  - jcranmer 8y ago
    > And this case is not likely to happen without a decent amount of notice. In the jurisdictions you care about. Last-minute timezone changes do happen, and the main time zone database has been updated retroactively in the past. It's actually possible that a timezone change has even been enacted retroactively (thanks to countries that like doing very last-minute DST starts).
    - BillinghamJ 8y ago
      Yeah indeed - for now we're fortunate that it's not something we need to worry about actually handling perfectly. It's more something we like to think about at this point. One day we will need to deal with it and conversations like these are super helpful to support that.
- ycombobreaker 8y ago
  If a time is designated as "local" it is most flexible to store the location in a way that will handle the dynamism. e.g. I would not record a time as "16:00 BST" but rather "16:00 Europe/London" and use the olson timezone db to resolve it to BST or GMT downstream.
- aocenas 8y ago
  You should definitely use geographic timezone like America/Los_Angeles instead of just offset. Offset actually isn't a real timezone it is just an offset. Timezone usually means a lookup table of what offset it has at what time and that can also change due to different laws at different time. So I assume the moment EU countries will change the rules there will be one more row for each timezone that will say "from this time the offset is such and such". That means it is also important to use the right timezone in the sense that even though Bratislava/SK and Prague/CZ have the same rules (DST time and offsets) at the moment they can change in different ways after the DST is removed (as whether to use winter or summer time afterwards is in jurisdiction of each country I think).
  - pmontra 8y ago
    I agree. In the only project I worked on where time was really important I stored a triple (original datetime, UTC timestamp, original time zone). I used UTC to globally sort events and sent the original datetime back to clients for display. On the other side, sometimes we don't know where an event happens. Think of GPS trackers close to a border which is also a timezone border. This is a more complex problem which requires at least a model of country borders and maybe roads. Finally, on some systems I'm using as a user, they have some EU timezones but not even all the major countries. It doesn't matter now but it will. I expect they'll add the missing timezones and make us confirm where we are.
jcranmer 8y ago
That doesn't solve the problem. Suppose Massachusetts were to decide to move from the Eastern to the Atlantic time zone and New York were to decide to remain in the Eastern time zone. The time zone you would need for people in Massachusetts would be America/Boston, not America/New_York--which doesn't exist now. Representing future times correctly is very hard, especially because time zone changes (including creation of new ones!) aren't always announced years in advance.
- hinkley 8y ago
  None of these tricks will help if I’m insuring myself for international travel. Only the trip to and from the airport is in the time zone of the policy. Any incidents along the way or after that are going to need an interpretation relative to UTC.
testvox 8y ago
Thanks for mentioning this. I came across this page which discusses the theory and practice of timezone databases. https://data.iana.org/time-zones/theory.html https://data.iana.org/time-zones/theory.html

heavenlyblue 8y ago

A question to both parent of this and this specifically. How would you deal with the current EU situation? They have recently voted to stop yearly transitions to summer time. But there must still be a timezone assigned to an event. Are you assigning timezones (in the certificates themselves) as the timezones of a particular geographic location,, rather than as time offsets?

deleted 8y ago
[deleted]
BillinghamJ 8y ago
On the certificates, we'd state e.g. "this policy runs from 27th March 2019 at 16:52:12 (GMT) to 3rd April 2019 at 17:52:12 (BST)" for a 168-hour (~7 day) policy. Logically, we think of it as the "wall clock" time, plus the location ("Europe/London" - we don't operate outside the UK yet), plus the local zone (BST/GMT) to handle ambiguity when clocks go back. Practically, right now the start/end date-times are stored using a Postgres timestamp with no timezone. As we've never issued an individual policy of more than 28 days' duration or more than 7 days in advance, we've never actually had to deal with any situation where the point-in-time is no longer correct. And this case is not likely to happen without a decent amount of notice. We're very much in favour of abolishing seasonal transitions though - causes lots of confusion.
- jcranmer 8y ago
  > And this case is not likely to happen without a decent amount of notice. In the jurisdictions you care about. Last-minute timezone changes do happen, and the main time zone database has been updated retroactively in the past. It's actually possible that a timezone change has even been enacted retroactively (thanks to countries that like doing very last-minute DST starts).
  - BillinghamJ 8y ago
    Yeah indeed - for now we're fortunate that it's not something we need to worry about actually handling perfectly. It's more something we like to think about at this point. One day we will need to deal with it and conversations like these are super helpful to support that.
ycombobreaker 8y ago
If a time is designated as "local" it is most flexible to store the location in a way that will handle the dynamism. e.g. I would not record a time as "16:00 BST" but rather "16:00 Europe/London" and use the olson timezone db to resolve it to BST or GMT downstream.
aocenas 8y ago
You should definitely use geographic timezone like America/Los_Angeles instead of just offset. Offset actually isn't a real timezone it is just an offset. Timezone usually means a lookup table of what offset it has at what time and that can also change due to different laws at different time. So I assume the moment EU countries will change the rules there will be one more row for each timezone that will say "from this time the offset is such and such". That means it is also important to use the right timezone in the sense that even though Bratislava/SK and Prague/CZ have the same rules (DST time and offsets) at the moment they can change in different ways after the DST is removed (as whether to use winter or summer time afterwards is in jurisdiction of each country I think).
- pmontra 8y ago
  I agree. In the only project I worked on where time was really important I stored a triple (original datetime, UTC timestamp, original time zone). I used UTC to globally sort events and sent the original datetime back to clients for display. On the other side, sometimes we don't know where an event happens. Think of GPS trackers close to a border which is also a timezone border. This is a more complex problem which requires at least a model of country borders and maybe roads. Finally, on some systems I'm using as a user, they have some EU timezones but not even all the major countries. It doesn't matter now but it will. I expect they'll add the missing timezones and make us confirm where we are.

jcranmer 8y ago

That doesn't solve the problem. Suppose Massachusetts were to decide to move from the Eastern to the Atlantic time zone and New York were to decide to remain in the Eastern time zone. The time zone you would need for people in Massachusetts would be America/Boston, not America/New_York--which doesn't exist now. Representing future times correctly is very hard, especially because time zone changes (including creation of new ones!) aren't always announced years in advance.

hinkley 8y ago
None of these tricks will help if I’m insuring myself for international travel. Only the trip to and from the airport is in the time zone of the policy. Any incidents along the way or after that are going to need an interpretation relative to UTC.

testvox 8y ago

Thanks for mentioning this. I came across this page which discusses the theory and practice of timezone databases. https://data.iana.org/time-zones/theory.html https://data.iana.org/time-zones/theory.html