On Thu, Dec 11, 2008 at 10:59 AM, Paul Koning
<Paul_Koning@dell.com> wrote:
>>>>> "Jennifer" == Jennifer Wang <(jennifwa)" <jennifwa@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