Re: DateTime bug & default timezone
On Wed, 26 Feb 2003, Eugene van der Pijll wrote:
> Dave Rolsky schreef:
> > > Solution: either specify 'utc' as the default time_zone in from_object(),
> > > or make 'floating' the default timezone in new().
> >
> > Or make floating the default in from_object.
>
> When converting DateTime -> DateTime, 'utc' makes more sense, as the utc
> rata die and seconds are used. In general, 'floating' could be better,
> as some calendars may not implement timezones, and _utc_rd_values
> returns 'floating' time values.
Hmm, good point. Maybe something like:
my $tz = $object->can('time_zone') ? 'UTC' : 'floating;
???
> > > I strongly suggest the second solution.
> >
> > Why?
>
> > ... While correct datetime math is unexpected
> > for various reason, I'm not sure that's an expectation I want to
> > propogate ;)
>
> I couldn't care less about datetime math. I will be using these modules
> to do _date math_. I don't care about and want to ignore times, seconds,
> leap seconds, timezones, DST and all that. My impression was that you
> meant DateTime to be a replacement for all date and/or time modules?
> That should mean that those people who want to specify only dates
> shouldn't have to specify a timezone to make it work.
>
> How about this example:
>
> $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.
> > > As an added bonus, changing to 'floating' as default removes the t/05tz
> > > out-of-memory bug. At least for me.
> >
> > Are you using the latest DateTime::TimeZone? I'm pretty sure this is
> > related to bugs in earlier versions, and if not it needs fixing, not
> > workarounds.
>
> DateTime-0.06, DT::TimeZone-0.08:
>
> when $TZ is set to '-0300', '+0300', or 'Foo', there's no problem;
> when $TZ is set to 'America/Chicago' or 'Europe/Amsterdam', t/05tz
> crashes at test 24.
I'll check this out.
> When the default in new() is changed to 'floating', the local timezone
> is obviously no longer important, and everything works OK. I don't know
> why, because 05tz uses a timezone in the call to new(). It seems like
> you create another DateTime object somewhere while not taking good care
> to specify a timezone.
>
> It seens that the way it is now encourages subtle bugs in the rest of
> DateTime, which are dependent on the users' environment and therefore
> hard to find...
Well, the bugs exist whether or not they're exposed by implementation
details, so they need fixing. But your arguments for defaulting to UTC or
floating are good ones.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime bug & default timezone
Dave Rolsky schreef:
> On Wed, 26 Feb 2003, Eugene van der Pijll wrote:
> > When converting DateTime -> DateTime, 'utc' makes more sense, as the utc
> > rata die and seconds are used. In general, 'floating' could be better,
> > as some calendars may not implement timezones, and _utc_rd_values
> > returns 'floating' time values.
>
> Hmm, good point. Maybe something like:
>
> my $tz = $object->can('time_zone') ? 'UTC' : 'floating;
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.
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.
> > $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.
2. All datetimes are local if the time is given; if no 'hour' parameter
is given to new() the datetime is floating.
3. All datetimes are local; if Eugene wants to use only the date part of
a datetime, he can write his own module.
Option 1 is perhaps the best; but also the most difficult to implement;
option 2 is probably impossible if you want to use Params::Validate;
option 3 is not my favorite.
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.
Eugene
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
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 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
> > 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 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
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. Excellent. - Bruce __bruce__van_allen__santa_cruz__ca__
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
