Re: DateTime bug & default timezone

[Bruce Van Allen]

On Saturday, March 1, 2003, at 07:21  AM, [EMAIL PROTECTED] wrote:
I'd say that the same applies .. add one month:
01:00 26 January 2003  + 1 month  = 01:00 26 February 2003
01:00 26 February 2003 + 2 months = 01:00 26 April 2003
On Friday, February 28, 2003, at 10:56  PM, Dave Rolsky wrote:
Hmm, I'm sure there are cases where people want the other 
implementation,
though.
I think that arises from fuzzy thinking.  Lots of people assume that 
date
units are reducable to seconds (I think influenced by years of working
with epoch seconds), but reducing discrete units like months, weeks, 
and
days to their time components is always going to produce weird
unpredictable results.

If they want to add the equivalent of 30 days in seconds vs. 1 month 
let
them do that, we could even provide some constants like SECS_IN_DAY to
make it easier.

I think like the earlier rule of thumb about dates start at 1, times 
start
at 0, it would be good rule of thumb that when adding date components 
the
time stays the same.
I agree with these thoughts and principles, but thinking of months as 
discrete units also has complications, as you say, with "weird 
unpredictable results":
# per above examples:
01:00 31 December 2002  + 2 months  = 01:00 31 February 2003 # NO
# 'End of Unit' date [0]:
01:00 31 December 2002  + 2 months  = 01:00 28 February 2003
# carryover -- but by what logic??
  day of month math: 31 - 28 = 3
01:00 31 December 2002  + 2 months  = 01:00 03 March 2003
  business month math: 31 December + 30 + 30
01:00 31 December 2002  + 2 months  = 01:00 01 March 2003

This DOES connect back to time of day, for example because compounding 
the discrepancies above with a few calculations could cross the cusp 
between Standard Time and Daylight Savings time, or NOT, depending on 
the month-adding logic.

Yes, the probability of that example is low, 'cause the time change 
isn't near the start of a month, just like the hour of the time change 
is at 02:00/01:00 rather than at midnight. But still.

I'd accept one or more arbitrary unit-adding methods, but not at the 
expense of unpredictably leaking hours.

[0] In composing calendar layouts for print and web, it's often 
necessary to know things like 'the end of the month', which determines 
how many days away something is, rather than the reverse.

  - Bruce

__bruce__van_allen__santa_cruz__ca__