Hi Sean,

On 9 April 2018 at 15:13, Sean P. DeNigris <s...@clipperadams.com> 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.


Reply via email to