time during standard to DST transition

[Jennifer Wang (jennifwa)]

>However, I still contend that these cases are different.  In the case
of a field that goes beyond its normal range, you can clearly 
>and unambiguously determine the user's intent, since mktime() was
designed to make it easy to do something like calculate a date that 
>is, say, 14 days in the future or past by simply adding or subtracting
fourteen days on the tm_mday field.   Then mktime() takes the 
>denormalized representation and does the right thing.
 
I agree it is unambiguous if this is how a caller uses mktime().
However, a caller could simply set the tm structure and enter an invalid
time.  mktime() makes a guess/adjustment in those cases not knowing
which direction caller wants to go.
 
Jennifer


________________________________

From: Scott Atwood [mailto:scott.roy.atwood at gmail.com] 
Sent: Thursday, December 11, 2008 11:15 AM
To: Paul Koning
Cc: tz at lecserver.nci.nih.gov; tz at lecserver.nci.nih.gov
Subject: Re: time during standard to DST transition


On Thu, Dec 11, 2008 at 10:59 AM, Paul Koning <Paul_Koning at dell.com>
wrote:


	>>>>> "Jennifer" == Jennifer Wang <(jennifwa)"
<jennifwa at cisco.com>> writes:
	
	 Jennifer> I think in most case when a caller sets the time to
2:10am
	 Jennifer> Mar 8, 2009 in America/Los_Angeles, he does not
realize
	 Jennifer> it's the "missing hour".  If he wants 1:10am (which
is a
	 Jennifer> valid time), he would use that.  So moving forward to
	 Jennifer> 3:10am seems to make sense.
	
	No, it doesn't.  If he meant 3:10 he would have said so.  There
is no
	basis at all to guess at the user's intent in this way.
	
	It's very simple.  The user is asking for a non-existent time.
So the
	reject is valid.  It is every bit as valid as an attempt to set
the
	current date/time to February 30th.



That's actually a poorly chosen example, since mktime() does guess the
users intent in a case like that, by normalizing fields that are out of
range.   February 30th would be normalized to March 1st or March 2nd
(depending on the year).


However, I still contend that these cases are different.  In the case of
a field that goes beyond its normal range, you can clearly and
unambiguously determine the user's intent, since mktime() was designed
to make it easy to do something like calculate a date that is, say, 14
days in the future or past by simply adding or subtracting fourteen days
on the tm_mday field.   Then mktime() takes the denormalized
representation and does the right thing.


In the case of the non-existent hour during a DST transition, there is
an inherent ambiguity, since you don't know if the caller added to or
subtracted from the tm_hour field to get to the invalid time.


-Scott

-- 
Scott Atwood

Cycle tracks will abound in Utopia.  ~H.G. Wells



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20081211/4db8a90d/attachment-0001.html