[Qt-interest] QDateTime daylight saving parsing time offset

[K. Frank]

Hello Paul and Atlant!

On Wed, Mar 30, 2011 at 1:27 PM, Atlant Schmidt
<aschmidt at dekaresearch.com> wrote:
> Paul:
>
>> Maybe it's just me but I've encountered so many bugs and issues with
>> date/time code, I always tend to tread carefully these days. I'd
>> rather ask stupid questions than wait for my app to break when the
>> clocks go back :-)
>
>  It's not just you. ;-)
>
>  Testing our embedded assumptions around transitions to
>  summertime/transitions from summertime/places that don't
>  transition at all/other miscellaneous timezone changes
>  and testing all of this assuming locations all around
>  the world is hard, challenging work.
>
>  Testing end-of-the-year rollover issues can be non-trivial.
>
>  Making plans for the run-out of 32-bit time_t in 2038 is
>  non-trivial. And much real-world software has a "time
>  window much wider than 1970-2038 so there's a lot of
>  hand-written "window-handler" code out there that also
>  factors-in to your testing.
>
>  A careful approach to date/time issues is always
>  warranted.
>
>                               Atlant
> ...

And what about when the government gets involved?

How about this use case:

I have some kind of calendar or appointment application.  I enter
a date for lunch for 12:00 noon, ET, April 1, 2012.  (That's "Eastern
Time" for the east coast of the U.S.)

Now how should the application store the time?  Presumably it
goes in as 12:00 noon EDT ("Eastern Daylight Time") because,
according to current law, daylight saving time goes into effect
in March.  But between now (when I enter the appointment)
and then (my lunch date), our esteemed legislators, in their
wisdom, change daylight saving time back to its April onset.
That is, on April 1, 2012, standard time (i.e., not daylight time)
is in effect.

For when should my application display my appointment?
For 12:00 noon (EST), or for 11:00 AM (EST) (which is the
12:00 noon EDT that the application originally stored)?

If the application says 11:00 AM, I go to lunch at 11:00 AM,
wait around until 11:30 AM, leave in a huff because my friend
stood me up, get mad at my (former) friend, and never speak
to him again.  (My friend comes at noon, gets mad at me
for standing him up, and so on...)

But actually my friend is right.  We made a date for lunch at
noon on April 1.

I would argue that the time should be stored as 12:00 noon
ET -- specifically ET, as distinct from either EDT or EST -- a
time value that is not yet a specific UTC time, but only becomes
specific and gets fixed as / rendered as 12:00 noon EDT or 12:00
noon EST when April 1, 2012 rolls around and we know whether
or not daylight saving is in effect.

After all, that's what we all mean when we say "Meet you at
noon on April 1."

Hey, it's just a thought...

Best.


K. Frank