Hi Sean, On 9 April 2018 at 15:13, Sean P. DeNigris <[email protected]> wrote: > Alistair Grant wrote >> I think using UTC would just move the problem by an hour. > > I'm not sure I understand. How so? I thought UTC is a constant reference > point unaffected by UTC (https://stackoverflow.com/a/5495816/424245)
The problem as you described it was that comparing times from just before midnight and just after midnight local time weren't equal. I haven't looked at the code or tested it, but I expect that if times were stored in UTC, instead of the problem happening just before and after midnight local time, it would happen just before and after midnight UTC time. I.e. by itself storing times as UTC wouldn't solve the problem. As has been mentioned by all the participants in this discussion there is also: - Date as a timespan vs. Date as a d/m/y - DST historical changes. This covers more than the start and end dates, in Australia there is a city that changed time zones altogether - it decided to move from Australian Central time to Australian Eastern time (from memory). - Named time zones vs Time zone offsets, e.g. is UTC + 2 hours CET in DST or Russia Time Zone 1 out of DST? - etc. So I'm not convinced that using UTC would solve the problem you originally reported. Having said that, I think that always storing UTC is the right thing to do. Which timezone to display in is up to the UI, and just having the offset by itself is insufficient - the timezone name is needed. Cheers, Alistair
