DateTime::Set set_time_zone fix
Thanks to Tim Mueller-Seydlitz and Matt Sisk, who found a couple of bugs in the DateTime::Set time zone handling. I'd like to have some feedback from you, before I put the fixed version on CPAN. You can get the new version from CVS, or send me a mail and I'll send you a tar file. You'll need to update Set::Infinite to version 0.59, it is also in CVS. These are the changes from DateTime::Set version 0.15: - fixed time zone handling in the methods: set_time_zone next/previous/closest/current - removed limitation of duration size in methods: add/add_duration subtract/subtract_duration - requires Set::Infinite 0.59 - uses iterate() experimental argument backtrack_callback - the following methods are now mutators: set_time_zone( $tz ) set( locale = $locale ) add( unit = $n ) add_duration( $dur ) subtract( unit = $n ) subtract_duration( $dur ) - fixed max/min of an infinite SpanSet - added test for infinite duration - from_recurrence() code cleanup - parameter checking: The 'dates' argument to from_datetimes() must be a list of DateTime objects That's all for now. - Flavio S. Glock
Re: DateTime::Set set_time_zone fix
I'm doing some tests with the revised version of DateTime::Set:
[EMAIL PROTECTED] wrote:
use DateTime::Event::Cron;
$cron = DateTime::Event::Cron-from_cron(cron = ' 15 18 * * 1-5');
$new_cron = $cron-clone()-set_time_zone('Europe/Berlin');
$date = DateTime-new( year = 2004, month = 6, day = 30,
hour = 17, minute= 10,
time_zone = 'Europe/London');
print $date-strftime(%a %F %T %Z\n);
# Wed 2004-06-30 17:10:00 GMT/BST
ok
$date = $date-clone()-set_time_zone('Europe/London');
print $date-strftime(%a %F %T %Z\n);
# Wed 2004-06-30 17:10:00 GMT/BST
ok
$next = $new_cron-next($date);
print $next-strftime(%a %F %T %Z\n);
# was: Wed 2004-06-30 19:15:00 CEST
I got Wed 2004-06-30 17:15:00 GMT/BST, it looks correct now.
This is the local London time, when cron ticks 18:15 in Berlin.
# Let's repeat the same operation as before
$date = DateTime-new( year = 2004, month = 6, day = 30,
hour = 17, minute= 10,
time_zone = 'Europe/London');
print $date-strftime(%a %F %T %Z\n);
# Wed 2004-06-30 17:10:00 GMT/BST
ok
$date = $date-clone()-set_time_zone('Europe/Berlin');
print $date-strftime(%a %F %T %Z\n);
# Wed 2004-06-30 18:10:00 CEST
ok
$next = $new_cron-next($date);
print $next-strftime(%a %F %T %Z\n);
# Wed 2004-06-30 18:15:00 CEST
ok.
This is the local Berlin time, when cron ticks 18:15 in Berlin.
It is the same time as before, but in a different time zone.
- Flavio S. Glock
localtime DateTime Objects
All I want is simple local time date time manipulation without having to deal with timezones. However, as illustrated below, I'm getting some weird (GMT?) results. Is this correct behavior? I'm using stock Red Hat 9 perl 5.8.0. = use DateTime; print DATE: . `date`; print DTNOW: . DateTime-now . \n; print DTABS: . new DateTime(month = 7, day = 1, year = 2004, hour = 14) . \n; = Output: DATE: Thu Jul 1 14:05:03 PDT 2004 DTNOW: 2004-07-01T21:05:03 DTABS: 2004-07-01T14:00:00 - Max
Re: localtime DateTime Objects
On 2 Jul 2004, at 7:13 AM, Max Campos wrote: All I want is simple local time date time manipulation without having to deal with timezones. However, as illustrated below, I'm getting some weird (GMT?) results. Is this correct behavior? I'm using stock Red Hat 9 perl 5.8.0. = use DateTime; print DATE: . `date`; print DTNOW: . DateTime-now . \n; DateTime-now() returns a UTC time unless given a time zone. Consider using: $dt = DateTime-now( time_zone = 'local' ); print DTABS: . new DateTime(month = 7, day = 1, year = 2004, hour = 14) . \n; On the other hand, DateTime-new() returns the local time zone unless otherwise instructed. Dave, can you enlighten me as to why this is the case? Shouldn't all constructors that don't have a time_zone attribute assume the same? (Which I'd prefer to be local if we can get it) While talking about local time zones, I'd like to again ask that during the install stage, the local zone can be set/confirmed. I'm sure you had a good reason not to do that, but I can't remember it. I'd also like to see a class based (rather than object based) ability to set the local time zone, probably through the import: use DateTime local = 'Australia/Melbourne'; Then all constructors would use that as the local (default) zone. Cheers! Rick Senior Developer PrintSupply - Print Procurement Supply Management 18 Greenaway Street VIC 3105 Tel: (03) 9850 3255 Fx: (03) 9850 3277 http://www.printsupply.com.au/
Re: localtime DateTime Objects
On 7/2/04 Rick Measham wrote: DateTime-now() returns a UTC time unless given a time zone. On the other hand, DateTime-new() returns the local time zone unless otherwise instructed. Dave, can you enlighten me as to why this is the case? Shouldn't all constructors that don't have a time_zone attribute assume the same? (Which I'd prefer to be local if we can get it) Some of us need non-localized times; i.e., floating. UTC as default is a Good Thing in some scientific contexts, for example. And for multi-location calcs, localization should be the last thing to be applied, not the first. But why DT-new() and DT-now() don't return the same thing, whichever it is, I don't recall. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: localtime DateTime Objects
On Fri, 2 Jul 2004, Rick Measham wrote: print DTABS: . new DateTime(month = 7, day = 1, year = 2004, hour = 14) . \n; On the other hand, DateTime-new() returns the local time zone unless otherwise instructed. No it doesn't. It uses floating. Dave, can you enlighten me as to why this is the case? Shouldn't all constructors that don't have a time_zone attribute assume the same? (Which I'd prefer to be local if we can get it) Didn't I just explain why now() (and today()) use UTC? It's cause we use gmtime(time) to get the value, so we actually know the time zone. While talking about local time zones, I'd like to again ask that during the install stage, the local zone can be set/confirmed. I'm sure you had a good reason not to do that, but I can't remember it. No reason. Patches welcome ;) I'd also like to see a class based (rather than object based) ability to set the local time zone, probably through the import: use DateTime local = 'Australia/Melbourne'; Then all constructors would use that as the local (default) zone. Hmm, that's an interesting idea. How about making it something you did with DateTime::TimeZone instead of DateTime? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: localtime DateTime Objects
On 2 Jul 2004, at 10:04 AM, Dave Rolsky wrote: On Fri, 2 Jul 2004, Rick Measham wrote: print DTABS: . new DateTime(month = 7, day = 1, year = 2004, hour = 14) . \n; On the other hand, DateTime-new() returns the local time zone unless otherwise instructed. No it doesn't. It uses floating. Sorry, I should have looked closer :] Dave, can you enlighten me as to why this is the case? Shouldn't all constructors that don't have a time_zone attribute assume the same? (Which I'd prefer to be local if we can get it) Didn't I just explain why now() (and today()) use UTC? It's cause we use gmtime(time) to get the value, so we actually know the time zone. Yes you did .. I forgot :) But, if we know the local time zone, then can't we use gmtime(time) to get UTC and then convert it into local? And why can't new() return a local time too unless asked for something else? Just so that all constructors return the same time zone. While talking about local time zones, I'd like to again ask that during the install stage, the local zone can be set/confirmed. I'm sure you had a good reason not to do that, but I can't remember it. No reason. Patches welcome ;) OK, I'll get them to you soon. I'd also like to see a class based (rather than object based) ability to set the local time zone, probably through the import: use DateTime local = 'Australia/Melbourne'; Then all constructors would use that as the local (default) zone. Hmm, that's an interesting idea. How about making it something you did with DateTime::TimeZone instead of DateTime? OK, it's better to have it in TimeZone because it's a time zone function, however as TimeZone comes in automatically when you use DateTime, can we have DateTime pass it onto TimeZone when it loads? Same as Flavio's suggestion with the locale forwarding to DateTime::Locale's DefaultLocale() class method. I'll send patches for your consideration on this also. Cheers! Rick Measham Senior Developer PrintSupply - Print Procurement Supply Management 18 Greenaway Street VIC 3105 Tel: (03) 9850 3255 Fx: (03) 9850 3277 http://www.printsupply.com.au/
