Re: time zone class method? (DT::F::MySQL)
On Thu, 6 Nov 2003, Rick Measham wrote: > But the same problem exists ... %parms will contain locale => > 'en_AU', so your call to set is now: > > $dt3->set( locale=>'en_AU', year=>2003 .. second => 27, time_zone => '-1100', > locale=>'latvia' > ); > > So which locale gets used? The second. It's entirely, deterministic, because it's being assigned in order to a hash, so last instance of a key always wins. In fact, that's perfectly valid Perl style, something like: my %params_to_use = ( %defaults, %user_overrides ); -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: time zone class method? (DT::F::MySQL)
At 21:57 -0600 2003-11-05, Matt Sisk wrote: Rick Measham wrote: The problem above is that $dt->parameters() may return a key included in %overrides. So how about $dt->parameters( %overrides )? As I corrected myself earlier, I should have made the $dt in $dt->parameters() more generic, rather than the self-same object. I was *deliberately* illustrating that you could override those parameters by flattening the hashes. So (a simple example...pretend I have several parameters to overide): %parms = $dt1->parameters; %overrides = (locale => 'latvia'); $dt3->set(%parms, %overrides); And as a convenience, I was suggesting this as equivalent: $dt3 = $dt1->clone(%overrides); But the same problem exists ... %parms will contain locale => 'en_AU', so your call to set is now: $dt3->set( locale=>'en_AU', year=>2003 .. second => 27, time_zone => '-1100', locale=>'latvia' ); So which locale gets used? Cheers! Rick
Re: time zone class method? (DT::F::MySQL)
On Wed, 5 Nov 2003, Matt Sisk wrote: > And as a convenience, I was suggesting this as equivalent: > > $dt3 = $dt1->clone(%overrides); If the set() method accepted a time_zone parameter (which is trivial to add), wouldn't this be equivalent to: $dt3 = $dt1->clone->set(%overrides); ?? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Mapping an offset to a datetime timezone
Dave Rolsky wrote: No, because there's plenty of timezones for every offset. For example, at -08:00 base offset from UTC we have America/Los_Angeles, America/Juneau, America/Whitehorse, America/Dawson, America/Tijuana, and America/Vancouver. So which one of those corresponds to -8 hours? It would be useful to be able to return a list of corresponding timezones, then the user could use whatever means they felt appropriate to select from the list (the application, I imagine, would be the determining factor in what this would be used for) Matt
RE: Mapping an offset to a datetime timezone
Hi Dave, > > On Wed, 5 Nov 2003, Hill, Ronald wrote: > > > I have recently updated the test scripts for the > > Astro::Sunrise module and would like to incorporate these > > changes into the DateTime::Event::Sunrise test suite. However, > > I am unable to map an offset into a datetime timezone. Is > > there a way to take an offset say -8 hours and look this up > > and know that this is America/Los_Angeles timezone? > > Dave Wrote: > > No, because there's plenty of timezones for every offset. > For example, at > -08:00 base offset from UTC we have America/Los_Angeles, > America/Juneau, > America/Whitehorse, America/Dawson, America/Tijuana, and > America/Vancouver. > > So which one of those corresponds to -8 hours? > I kinda figured it would be like that (It does'nt hurt to ask). However, I was able to figure out what I need to do: I am using the offset_as_string method from DateTime::TimeZone module to set it. Now I just need to figure out how to round either up or down to the nearest minite. I will post the script to the group when I am done :) Thanks Ron Hill
Re: Mapping an offset to a datetime timezone
On Wed, 5 Nov 2003, Hill, Ronald wrote: > I have recently updated the test scripts for the > Astro::Sunrise module and would like to incorporate these > changes into the DateTime::Event::Sunrise test suite. However, > I am unable to map an offset into a datetime timezone. Is > there a way to take an offset say -8 hours and look this up > and know that this is America/Los_Angeles timezone? No, because there's plenty of timezones for every offset. For example, at -08:00 base offset from UTC we have America/Los_Angeles, America/Juneau, America/Whitehorse, America/Dawson, America/Tijuana, and America/Vancouver. So which one of those corresponds to -8 hours? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: time zone class method? (DT::F::MySQL)
On Wed, 5 Nov 2003, Matt Sisk wrote:
> Was there a compelling reason not to have a class method analagous to
> DefaultLocale() for timezones, such as DefaultTimezone()?
Nope, no particular reason. But thinking about it, it seems like a bad
idea. Locale is something that I would think the end user always wants to
set for themselves. OTOH, the standard of "absent a time zone, we use
floating" makes it easy for people to write modules that use DateTime
stuff internally without having to worry about the user have set the
default time zone for their own code.
It strikes me as potentially dangerous action at a distance, because
setting the time zone can impact a _lot_ of calculations, whereas setting
the locale impacts nothing except presentation, which shouldn't be the
concern of CPAN modules using DateTime internally.
> DateTimes:
>
> use DateTime;
> use DateTime::Format::MySQL;
>
> $F = 'DateTime::Format::MySQL';
>
> $now = DateTime->now(time_zone => 'local');
> print "now: ", $now->datetime, "\n";
> print "tz: ", $now->time_zone_long_name, "\n";
> $mdt = $F->format_datetime($now);
> print "mdt: $mdt\n";
> $now = $F->parse_datetime($mdt);
> print "now2: ", $now->datetime, "\n";
> print "tz2: ", $now->time_zone_long_name, "\n";
> $now->set_time_zone('local');
> print "now2: ", $now->datetime, "\n";
> print "tz2: ", $now->time_zone_long_name, "\n";
>
> In order to get symmetry, you have to first set_time_zone('UTC') to
> convert from 'floating', then set_time_zone('local') to get back to the
> original time.
>
> Am I going about this the wrong way?
No, this probably just needs some documentation in DT::F::MySQL about how
to handle the results of parsing.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: parse_datetime and format_datetime
On Wed, 5 Nov 2003, Matt Sisk wrote: > Just out of curiousity...why the '_datetime' suffix on these methods? > Isn't that redundant? Or was it assuming that these methods might be > showing up in classes outside of the DateTime namespace? Because we can parse and format things that aren'ts datetimes, like dates, durations, spans, etc. > And speaking of brevity...the 0.18 docs for DateTime say that > 'time_zone_long_name' is short for $dt->tz->name. I see no evidence of a > 'tz' method, though it'd be nice to have around, along with 'tz_name', etc. That should say "short for $dt->time_zone->long_name". I'm not that big on brevity, sorry ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Mapping an offset to a datetime timezone
Hi All, I have recently updated the test scripts for the Astro::Sunrise module and would like to incorporate these changes into the DateTime::Event::Sunrise test suite. However, I am unable to map an offset into a datetime timezone. Is there a way to take an offset say -8 hours and look this up and know that this is America/Los_Angeles timezone? Thanks Ron Hill
Re: New module
* Dean Thayer ([EMAIL PROTECTED]) [05 Nov 2003 11:04]:
> Is anyone working on a module to convert time strings in the format
> used by Tivoli Enterprise Console to DateTime objects? I was going to
> do so, and I figured I would check. Also, would you want that module
> included in the DateTime bundle, or should I simply put it in the
> Tivoli::TEC module I was planning on writing? The Tivoli Enterprise
> Console date string format in strftime(3c) format is:
> %h %e %k:%M:%S %Y
Hmm. This right?
package DateTime::Format::Tivoli;
use DateTime::Format::Builder
parsers => {
parse_datetime => {
strptime => '%h %e %k:%M:%S %Y',
},
}
;
sub format_datetime
{
my ($self, $dt) = @_;
my $z = $dt->clone->set_time_zone( 'GMT' );
return $z->strftime( '%h %e %k:%M:%S %Y' );
}
1;
__END__
cheers,
--
Iain.
pgp0.pgp
Description: PGP signature
Re: parse_datetime and format_datetime
> Just out of curiousity...why the '_datetime' suffix on these methods? > Isn't that redundant? Or was it assuming that these methods might be > showing up in classes outside of the DateTime namespace? To differentiate from: _date, _time, _span, etc. > And speaking of brevity...the 0.18 docs for DateTime say that > 'time_zone_long_name' is short for $dt->tz->name. I see no evidence of a > 'tz' method, though it'd be nice to have around, along with 'tz_name', etc. 'tz' is a key in the blessed hash of a DateTime object. The docs should say "$dt->time_zone->name". -J --
time zone class method? (DT::F::MySQL)
Was there a compelling reason not to have a class method analagous to
DefaultLocale() for timezones, such as DefaultTimezone()?
And if it were present, am I alone in finding it useful for the Format
modules, such as DT::F::MySQL, where the zoneless strings are forced
into the 'floating' timezone?
Although it is not strictly true that MySQL is timezone agnostic. You
could construct a local datetime using the result of MySQL's
UNIX_TIMESTAMP() function with DateTime's from_epoch() and set the tz to
'local' -- the unix timestamp returned from MySQL appears to observe the
timezone of the local machine.
As it now stands, DT::F::MySQL does not behave symmetrically for local
DateTimes:
use DateTime;
use DateTime::Format::MySQL;
$F = 'DateTime::Format::MySQL';
$now = DateTime->now(time_zone => 'local');
print "now: ", $now->datetime, "\n";
print "tz: ", $now->time_zone_long_name, "\n";
$mdt = $F->format_datetime($now);
print "mdt: $mdt\n";
$now = $F->parse_datetime($mdt);
print "now2: ", $now->datetime, "\n";
print "tz2: ", $now->time_zone_long_name, "\n";
$now->set_time_zone('local');
print "now2: ", $now->datetime, "\n";
print "tz2: ", $now->time_zone_long_name, "\n";
In order to get symmetry, you have to first set_time_zone('UTC') to
convert from 'floating', then set_time_zone('local') to get back to the
original time.
Am I going about this the wrong way?
Thanks,
Matt
parse_datetime and format_datetime
Just out of curiousity...why the '_datetime' suffix on these methods? Isn't that redundant? Or was it assuming that these methods might be showing up in classes outside of the DateTime namespace? And speaking of brevity...the 0.18 docs for DateTime say that 'time_zone_long_name' is short for $dt->tz->name. I see no evidence of a 'tz' method, though it'd be nice to have around, along with 'tz_name', etc. Thanks, Matt
