3 ms·

In my view, ZonedTime<Z> needs to exist, such that it isn't even a complete type without an actual time zone, and you can convert between ZonedTime<PDT> and Zon

by msla 7y ago

In my view, ZonedTime<Z> needs to exist, such that it isn't even a complete type without an actual time zone, and you can convert between ZonedTime<PDT> and ZonedTime<CEST> with a cast. Of course, I'd also have DurationTime as its own type, and do whatever magic is needed to ensure it remains uninfected by leap second shifts.

Macha 7y ago
I used to think that way - just treat date times like string encoding. Pick your desired format (UTC/UTF-8), convert into it on input, convert from it on output as needed. But it turns out there are situations where it does matter. If you ever run into a multi-timezone calendar problem, this approach breaks down. A couple of examples of where it doesn't work: * My alarms needs to wake me up at 8am. If I am at home, this should be 8am Irish time. If I relocate myself to the US, it should be 8am in whatever US timezone is currently in effect for my location. * I want to schedule something to happen all day Irish time next Christmas. From 00:00 to 23:59. In the meantime, the EU actually abolishes DST: https://www.npr.org/2019/03/27/707179979/european-parliament-moves-toward-ending-daylight-saving-time https://www.npr.org/2019/03/27/707179979/european-parliament... - The UTC conversion of 2020-12-25T00:00:00[Europe/Dublin] today gets converted to 2020-12-25T01:00:00[Europe/Dublin] when you try invert it in christmas 2020. Both these situations are resolved with local dates/times. The first one should just be a local date, while the second one requires the combination of the local date and the timezone to happen at time of check, not at time of input.
- msla 7y ago
  > I used to think that way - just treat date times like string encoding. Pick your desired format (UTC/UTF-8), convert into it on input, convert from it on output as needed. Not quite what I had in mind, but I suppose you could serialize a ZonedTime<Z> to a string, like you can serialize an integer to a string. > Both these situations are resolved with local dates/times. The first one should just be a local date, while the second one requires the combination of the local date and the timezone to happen at time of check, not at time of input. Right. The first example requires a different type, LocalTime, and the second example requires types to change interpretation over time. Neither of these are problems with my scheme. They're problems with UI and system administration.

by msla 7y ago

Macha 7y ago

I used to think that way - just treat date times like string encoding. Pick your desired format (UTC/UTF-8), convert into it on input, convert from it on output as needed. But it turns out there are situations where it does matter. If you ever run into a multi-timezone calendar problem, this approach breaks down. A couple of examples of where it doesn't work: * My alarms needs to wake me up at 8am. If I am at home, this should be 8am Irish time. If I relocate myself to the US, it should be 8am in whatever US timezone is currently in effect for my location. * I want to schedule something to happen all day Irish time next Christmas. From 00:00 to 23:59. In the meantime, the EU actually abolishes DST: https://www.npr.org/2019/03/27/707179979/european-parliament-moves-toward-ending-daylight-saving-time https://www.npr.org/2019/03/27/707179979/european-parliament... - The UTC conversion of 2020-12-25T00:00:00[Europe/Dublin] today gets converted to 2020-12-25T01:00:00[Europe/Dublin] when you try invert it in christmas 2020. Both these situations are resolved with local dates/times. The first one should just be a local date, while the second one requires the combination of the local date and the timezone to happen at time of check, not at time of input.

msla 7y ago
> I used to think that way - just treat date times like string encoding. Pick your desired format (UTC/UTF-8), convert into it on input, convert from it on output as needed. Not quite what I had in mind, but I suppose you could serialize a ZonedTime<Z> to a string, like you can serialize an integer to a string. > Both these situations are resolved with local dates/times. The first one should just be a local date, while the second one requires the combination of the local date and the timezone to happen at time of check, not at time of input. Right. The first example requires a different type, LocalTime, and the second example requires types to change interpretation over time. Neither of these are problems with my scheme. They're problems with UI and system administration.