Re: DateTime bug default timezone
On Tue, 11 Mar 2003 10:46:32 -0800, [EMAIL PROTECTED] wrote: On Monday, March 10, 2003, at 07:10 PM, Dave Rolsky wrote: On Sat, 1 Mar 2003, Bruce Van Allen wrote: I agree with these thoughts and principles, but thinking of months as discrete units also has complications, as you say, with weird unpredictable results: [snip] That's why there is an eom_mode (end of month mode) parameter for the DateTime::Duration constructor, which allows you to control how adding months is handled. I think the parameter got renamed to end_of_month. Excellent. - Bruce In your examples, you showed a business month=30 days calculation. Should we have such a 'business' mode? Existing modes are wrap (the default), limit, and preserve: Assuming adding X months to month M, day D: wrap will give D-1 days after the first of month M+X limit will give month M+X with the day being the earlier of D and the last day of the month preserve will give the last day of month M+X if D is the last day of M; otherwise it will give the same result as limit On another topic, just below add_duration in DateTime.pm, I see this: use constant INFINITY = 100 ** 100 ** 100 ; use constant NEG_INFINITY = -1 * (100 ** 100 ** 100); I remember this (how to produce an numeric infinity) coming up on perl5-porters and seem to recall that the above just coredumps on some platforms.
Re: DateTime bug default timezone
Yitzchak Scott-Thoennes wrote: use constant INFINITY = 100 ** 100 ** 100 ; use constant NEG_INFINITY = -1 * (100 ** 100 ** 100); I remember this (how to produce an numeric infinity) coming up on perl5-porters and seem to recall that the above just coredumps on some platforms. The idea came from a perlmonks discussion. I've got positive reports from mac, pc, linux and sun users. I'll look into perl5-porters... - Flavio S. Glock
Re: DateTime bug default timezone
Yitzchak Scott-Thoennes wrote: On another topic, just below add_duration in DateTime.pm, I see this: use constant INFINITY = 100 ** 100 ** 100 ; use constant NEG_INFINITY = -1 * (100 ** 100 ** 100); I remember this (how to produce an numeric infinity) coming up on perl5-porters and seem to recall that the above just coredumps on some platforms. There is something here: http://aspn.activestate.com/ASPN/Mail/Message/1395647 On Mon, Oct 14, 2002 at 02:49:54PM +0300, Jarkko Hietaniemi wrote: It seems that '2**1' produces zero with gcc 3.2.1 in Tru64 5.1A, which is of course a bug to itself, but at least this pack.t test [more] - Flavio S. Glock
Re: DateTime bug default timezone
On Sat, 1 Mar 2003, Bruce Van Allen wrote: 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 That's why there is an eom_mode (end of month mode) parameter for the DateTime::Duration constructor, which allows you to control how adding months is handled. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime bug default timezone
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 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. kellan
Re: DateTime bug default timezone
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__
Re: DateTime bug default timezone
On Thu, 27 Feb 2003, Rick Measham wrote: I think if I add 'one day' then the time is the same, regardless of DST cusp. Only the day increases. If I add '24 hours' then at the DST cusp the time would change, as would the day. Ok, that's easy. But what about months? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime bug default timezone
At 11:28 PM -0600 28/2/03, Dave Rolsky wrote: On Thu, 27 Feb 2003, Rick Measham wrote: I think if I add 'one day' then the time is the same, regardless of DST cusp. Only the day increases. If I add '24 hours' then at the DST cusp the time would change, as would the day. Ok, that's easy. But what about months? 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 Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: DateTime bug default timezone
On Sat, 1 Mar 2003, Rick Measham wrote: Ok, that's easy. But what about months? 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 Hmm, I'm sure there are cases where people want the other implementation, though. I'm starting to think this may need two different methods, which would be a PITA. Plus I'm afraid of making the module too confusing. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime bug default timezone
Dave Rolsky wrote: So does anybody reading this object to me changing the default time zone to UTC? I think UTC is better than floating here simply because it's easier to explain. I understand that a 'floating' date object has less information on it than a 'UTC' date object, since the floating date doesn't have a timezone. That's why I would prefer the 'floating' default - it means 'timezone is not specified'. - Flavio S. Glock
Re: DateTime bug default timezone
On Wed, 26 Feb 2003, Eugene van der Pijll wrote:
If $object-can('time_zone'), the _utc_rd_values should be interpreted
as 'utc', but you can just take the $object-timezone (and clone it?)
and use that.
True. Time zone objects are actually singletons, so no need to clone
anything.
Of course, this assumes that all modules that have a time_zone() method
use the same time zones. For clocks with different hours and minutes,
like the French revolutionary clock, this might not be the case... On
the other hand, they didn't really have time zones then.
If anyone knows of another time zone system, I'd like to hear about it (or
maybe not, I don't need more headaches ;)
$d = DateTime-new( year = 2002, month = 10, day = 24 );
$d += DateTime::Duration-new( weeks = 1 );
print $d-ymd, \n;
This prints 2002-10-30...
That's a good argument.
There are of course other solutions:
0. All datetimes are floating (or utc) unless a timezone is given.
1. Remove the default values for hour/minute/second; if no times are
given, these values are undef, and no time calculations (including TZ
and DST) are done.
These two are actually more or less the same. If an object's TZ if
floating or UTC, then adding days/weeks/months/years should never change
the time.
2. All datetimes are local if the time is given; if no 'hour' parameter
is given to new() the datetime is floating.
Too magical ;)
3. All datetimes are local; if Eugene wants to use only the date part of
a datetime, he can write his own module.
Nah, too many similar modules ;)
I don't think there's any reason this module can't do both complicated
time zone stuff _and_ simple date-only math. Certainly with the floating
or UTC time zones available, this is possible.
I'm not particularly wedded to defaulting to local as the time zone
really. I was just doing what Date::ICal did for lack of a better
suggestion. It seems to me that default to floating or UTC might be a lot
more straightforward. If you want to the time zone calculations as well,
it's easy enough to get.
So does anybody reading this object to me changing the default time zone
to UTC? I think UTC is better than floating here simply because it's
easier to explain.
Oh, I forgot one: datetime assumes that adding 1 day is the same as
adding 24 hours:
print $d = DateTime-new( year = 2002,
month = 10,
day = 27,
time_zone = 'Europe/Amsterdam' ),
\n,
$d += DateTime::Duration-new( days = 1 ),
\n;
Sun, 27 Oct 2002 00:00:00 CEST
Sun, 27 Oct 2002 23:00:00 CET
Is this correct? I would say no, but I know that there are those who
disagree.
This has to do with the internal implementation, which is to add things to
the UTC Rata Die days and seconds values, and then re-calculate the local
time. If someone adds hours, minutes, or seconds explcitly, this is
definitely the right approach. But if they add days or months, it's not
clear which is correct. It might be better to add it to the local time
and re-calculate UTC.
What do others think?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime bug default timezone
On 27/2/03 10:33 am, Dave Rolsky at [EMAIL PROTECTED] spake thus: This has to do with the internal implementation, which is to add things to the UTC Rata Die days and seconds values, and then re-calculate the local time. If someone adds hours, minutes, or seconds explcitly, this is definitely the right approach. But if they add days or months, it's not clear which is correct. It might be better to add it to the local time and re-calculate UTC. What do others think? I think if I add 'one day' then the time is the same, regardless of DST cusp. Only the day increases. If I add '24 hours' then at the DST cusp the time would change, as would the day. Cheers! Rick There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners
