<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3429" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=265475123-11122008>></SPAN>However, I still contend that these cases
are different. In the case of a field that goes beyond its normal range,
you can clearly </FONT></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=265475123-11122008>></SPAN></FONT></FONT></FONT><FONT face=Arial><FONT
color=#0000ff><FONT size=2>and unambiguously determine the user's intent,
since mktime() was designed to make it easy to do something like calculate a
date that </FONT></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=265475123-11122008>></SPAN>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 </FONT></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=265475123-11122008>></SPAN>denormalized representation and does the
right thing.</FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2>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<SPAN class=296414523-11122008> </SPAN>guess/adjustment in those
cases<SPAN class=265475123-11122008> not knowing which direction caller wants to
go</SPAN>.</FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff
size=2></FONT> </DIV>
<DIV dir=ltr align=left><SPAN class=265475123-11122008><FONT face=Arial
color=#0000ff size=2>Jennifer</FONT></SPAN></DIV><FONT face=Arial color=#0000ff
size=2></FONT><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Scott Atwood
[mailto:scott.roy.atwood@gmail.com] <BR><B>Sent:</B> Thursday, December 11, 2008
11:15 AM<BR><B>To:</B> Paul Koning<BR><B>Cc:</B> tz@lecserver.nci.nih.gov;
tz@lecserver.nci.nih.gov<BR><B>Subject:</B> Re: time during standard to DST
transition<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=gmail_quote>On Thu, Dec 11, 2008 at 10:59 AM, Paul Koning <SPAN
dir=ltr><<A
href="mailto:Paul_Koning@dell.com">Paul_Koning@dell.com</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">>>>>>
"Jennifer" == Jennifer Wang <(jennifwa)" <<A
href="mailto:jennifwa@cisco.com">jennifwa@cisco.com</A>>>
writes:<BR><BR> Jennifer> I think in most case when a caller sets the
time to 2:10am<BR> Jennifer> Mar 8, 2009 in America/Los_Angeles, he
does not realize<BR> Jennifer> it's the "missing hour". If he
wants 1:10am (which is a<BR> Jennifer> valid time), he would use that.
So moving forward to<BR> Jennifer> 3:10am seems to make
sense.<BR><BR>No, it doesn't. If he meant 3:10 he would have said so.
There is no<BR>basis at all to guess at the user's intent in this
way.<BR><BR>It's very simple. The user is asking for a non-existent
time. So the<BR>reject is valid. It is every bit as valid as an
attempt to set the<BR>current date/time to February 30th.</BLOCKQUOTE>
<DIV><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial color=#0000ff
size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><BR></DIV>
<DIV>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).</DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial color=#0000ff
size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial
color=#0000ff size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><FONT
face=Arial color=#0000ff size=2></FONT><BR></DIV>
<DIV>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.</DIV></DIV>
<DIV class=gmail_quote><FONT face=Arial color=#0000ff size=2></FONT><FONT
face=Arial color=#0000ff size=2></FONT><FONT face=Arial color=#0000ff
size=2></FONT><BR></DIV>
<DIV class=gmail_quote>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.</DIV>
<DIV class=gmail_quote><FONT face=Arial color=#0000ff size=2></FONT><FONT
face=Arial color=#0000ff size=2></FONT><BR></DIV>
<DIV class=gmail_quote>-Scott</DIV><BR>-- <BR>Scott Atwood<BR><BR>Cycle tracks
will abound in Utopia. ~H.G. Wells<BR><BR><BR></BODY></HTML>