time during standard to DST transition
Hello, We ran into a problem when setting time to the "missing hour" during transition from standard time to DST time. For example, setting time to Mar 8, 2009 at 2:10am using America/Los_Angeles time zone results in error. Should mktime() skip forward in this case and set the time to Mar 8, 2009 3:10am? Jennifer
On Wed, Dec 10, 2008 at 10:43 AM, Jennifer Wang (jennifwa) < jennifwa@cisco.com> wrote:
Hello,
We ran into a problem when setting time to the "missing hour" during transition from standard time to DST time. For example, setting time to Mar 8, 2009 at 2:10am using America/Los_Angeles time zone results in error.
Should mktime() skip forward in this case and set the time to Mar 8, 2009 3:10am?
To me, it seems to make sense to return an error. The time 2:10am Mar 8, 2009 in America/Los_Angeles really is an ambiguous time. You can't determine the intension of the caller. She could either be counting forward one hour from 1:10am, or she could be counting back one hour from 3:10am, which result in different answers. Likewise, calling mktime() with 2:10am, Nov 2, 2008 in America/Los_Angeles and a negative value of tm_isdst is similarly ambiguous. I think both of these cases should return an error. -Scott -- Scott Atwood Cycle tracks will abound in Utopia. ~H.G. Wells
I think in most case when a caller sets the time to 2:10am Mar 8, 2009 in America/Los_Angeles, he does not realize it's the "missing hour". If he wants 1:10am (which is a valid time), he would use that. So moving forward to 3:10am seems to make sense. There are also other code such as normalize_overflow() where we make adjustments to what caller wants. Jennifer ________________________________ From: Scott Atwood [mailto:scott.roy.atwood@gmail.com] Sent: Wednesday, December 10, 2008 11:26 AM To: tz@elsie.nci.nih.gov; Jennifer Wang (jennifwa) Subject: Re: time during standard to DST transition On Wed, Dec 10, 2008 at 10:43 AM, Jennifer Wang (jennifwa) <jennifwa@cisco.com> wrote: Hello, We ran into a problem when setting time to the "missing hour" during transition from standard time to DST time. For example, setting time to Mar 8, 2009 at 2:10am using America/Los_Angeles time zone results in error. Should mktime() skip forward in this case and set the time to Mar 8, 2009 3:10am? To me, it seems to make sense to return an error. The time 2:10am Mar 8, 2009 in America/Los_Angeles really is an ambiguous time. You can't determine the intension of the caller. She could either be counting forward one hour from 1:10am, or she could be counting back one hour from 3:10am, which result in different answers. Likewise, calling mktime() with 2:10am, Nov 2, 2008 in America/Los_Angeles and a negative value of tm_isdst is similarly ambiguous. I think both of these cases should return an error. -Scott -- Scott Atwood Cycle tracks will abound in Utopia. ~H.G. Wells
"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. paul
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 -- Scott Atwood Cycle tracks will abound in Utopia. ~H.G. Wells
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@gmail.com] Sent: Thursday, December 11, 2008 11:15 AM To: Paul Koning Cc: tz@lecserver.nci.nih.gov; tz@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@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 -- Scott Atwood Cycle tracks will abound in Utopia. ~H.G. Wells
participants (3)
-
Jennifer Wang (jennifwa) -
Paul Koning -
Scott Atwood