On Wednesday, March 12, 2003, at 01:02 PM, Dave Rolsky wrote:
On Tue, 11 Mar 2003, Bruce Van Allen wrote:Are you saying you'd do the carryover yourself, or you expect DateTime.pmUpon catching that exception, I think I would always do a "carryover" operation, so the result in both cases would be 2003-04-06T03:00:00 w/ DST flag set.
to do it?
I'm saying it will have to be done, so I'd do it if DT doesn't. See below.
The rule for the end of DST, as you mentioned,"First" wins, where first is defined as "earliest UTC datetime".has withstood every test I've thrown at it.
I guess you're assuming that 03:00:00 wouldn't *always* be the expected
result (at local start of DST)?
No, this had to do with the switch from saving to standard, where here in
the US 1:59 AM (saving) is followed by 1:00 AM (standard). So the
question was what should be done if the user asks for "1:30 AM" on the day
the switch occurs, and my answer was that the earliest UTC time wins,
which always means saving time, not standard.
But this doesn't cause any exceptions, of course. The exceptions are
caused when the user does something that tries to produce a wall clock
time that doesn't exist, which can happen at the transition from standard
to saving.
You misunderstood me. In my paragraph starting "I guess you're assuming that 03:00..." I'm referring back to April, the *start* of DST. Sorry I didn't make that more clear. I like the way the end of DST is handled, but I don't like the way the start of DST is handled, because I'll have to cover for the exception (unless DT does ;-).
My question is really: is there an imaginable case where, on the start date of DST, the math shouldn't be 01:59:59 + 1 sec = 03:00:00 ?? If someone can demonstrate such a case, then DT should throw an exception; otherwise why not have DT do the "carryover"?
- Bruce
__bruce__van_allen__santa_cruz__ca__
