Re: localtime DateTime Objects
On Fri, 2 Jul 2004, Tim Bunce wrote:
On Thu, Jul 01, 2004 at 07:04:54PM -0500, Dave Rolsky wrote:
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?
I think it's dangerous unless it can be lexically scopped (which
is can't be easily).
It's trvial for an application which wants that behaviour to subclass
DateTime etc as needed to supply local defaults.
Well, setting the _local_ timezone to some default isn't dangerous. As it
stands, using local as the time zone will give you unpredictable
results. On some systems (Win32), we _know_ it will throw an exception
unless $ENV{TZ} is set, because we can't get the time zone from the OS.
So no CPAN module should _ever_ be using this at all. It's really
provided for users who know exactly where there code will be deployed.
For example, if you're writing code that will be deployed across a set of
servers your company controls around the world, you can safely use this if
you are sure that the time zone is set properly on all of them.
I should probably document this more completely.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
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/
