[Qt-interest] QDateTime daylight saving parsing time offset

[Atlant Schmidt]

K. Frank:

  You need one more refinement, though (which you may
  have assumed but didn't explicitly state).

  Your appointment needs its "modified time zone" (e.g.,
  "ET") stored with it. The calendar program then needs
  to be aware of all of the pending appointments and how
  they relate to the current local time on the calendar
  device.*

  That way, when you're traveling in Kuala Lumpur and
  it's 02:00 in the middle of the night on the next day,
  your calendar device can wake you up and remind you
  that you're due at lunch with your friend back in
  the ET time zone. Well, maybe we need to think about
  this some more ;-).

                             Atlant



* I leave this as an exercise to the reader, but I suspect
  it involves a list of appointments, adjusted (and
  occasionally re-adjusted!) to UTC and kept in sorted
  (and occasionally, re-sorted) order by their updated
  UTC time.


  All in all, maybe Indiana and Arizona had the right idea?
  (For non-US readers, these are the two United States
  states that *DON'T* adjust their clocks for "Summer Time".)


-----Original Message-----
From: qt-interest-bounces+aschmidt=dekaresearch.com at qt.nokia.com [mailto:qt-interest-bounces+aschmidt=dekaresearch.com at qt.nokia.com] On Behalf Of K. Frank
Sent: Wednesday, March 30, 2011 14:15
To: Qt-interest
Subject: Re: [Qt-interest] QDateTime daylight saving parsing time offset

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
_______________________________________________
Qt-interest mailing list
Qt-interest at qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-interest

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.