Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DateTime-Format-Strptime CPAN distribution.

Report information
The Basics
Id: 74762
Status: resolved
Priority: 0/
Queue: DateTime-Format-Strptime

People
Owner: Nobody in particular
Requestors: DOUGW [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 1.5000
Fixed in:
  • 1.66
  • 1.67
  • 1.68



I understand that time zone 'PST' is ambiguous. But it would be nice to either document the internal %ZONEMAP variable, or provide a method so that ambiguous timezones can be set to something unambiguous. Currently I can do: $DateTime::Format::Strptime::ZONEMAP{PST} = '-0800'; etc. Then I can parse a string with timezone PST, but I hesitate to do that since ZONEMAP is undocumented, and the internals could change.
On Tue Feb 07 19:38:20 2012, DOUGW wrote: Show quoted text
> > Then I can parse a string with timezone PST, but I hesitate to do that > since ZONEMAP is undocumented, and the internals could change.
And here is a patch to document %ZONEMAP. Might be nicer to also add a method or config option on the constructor to localize changes to a format object, but I think this is good enough(tm) for now and simpler.
Subject: Strptime.diff.txt
--- Strptime.pm Wed Feb 8 09:43:45 2012 +++ Strptime.pm Wed Feb 8 10:04:08 2012 @@ -1411,6 +1411,15 @@ =back +=head1 AMBIGUOUS TIME ZONE NAMES + +Some time zones (e.g. 'PST', 'EDT', 'EST') are ambiguous, and so will not be parsed. +However, if you wish to define an offset for a time zones name, then +you can use the package variable C<%DateTime::Format::Strptime::ZONEMAP> to +map the name to some UTC offset. E.g.: + + $DateTime::Format::Strptime::ZONEMAP{PST} = '-0800'; + =head1 AUTHOR EMERITUS This module was created by Rick Measham.
Subject: Re: [rt.cpan.org #74762] Allow option to define ambiguous timezones
Date: Wed, 8 Feb 2012 12:23:43 -0600 (CST)
To: Douglas Wilson via RT <bug-DateTime-Format-Strptime [...] rt.cpan.org>
From: Dave Rolsky <autarch [...] urth.org>
On Wed, 8 Feb 2012, Douglas Wilson via RT wrote: Show quoted text
> And here is a patch to document %ZONEMAP. Might be nicer to also add a > method or config option on the constructor to localize changes to a > format object, but I think this is good enough(tm) for now and simpler.
This sort of global setting just doesn't work. What if two pieces of code want to set this? -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/
On Wed Feb 08 13:23:51 2012, autarch@urth.org wrote: Show quoted text
> On Wed, 8 Feb 2012, Douglas Wilson via RT wrote: > > This sort of global setting just doesn't work. What if two pieces of code > want to set this?
It does just work when you know you want the setting to be global. Like I said, additional options to set it at the object level would be nice, but there's nothing wrong with a global option if you know the impact (and it still allows use of local() if needed in any specific case).
Subject: Re: [rt.cpan.org #74762] Allow option to define ambiguous timezones
Date: Wed, 8 Feb 2012 15:39:37 -0600 (CST)
To: Douglas Wilson via RT <bug-DateTime-Format-Strptime [...] rt.cpan.org>
From: Dave Rolsky <autarch [...] urth.org>
On Wed, 8 Feb 2012, Douglas Wilson via RT wrote: Show quoted text
> It does just work when you know you want the setting to be global. Like > I said, additional options to set it at the object level would be nice, > but there's nothing wrong with a global option if you know the impact > (and it still allows use of local() if needed in any specific case).
Imagine two CPAN module, or two parts of a large code base, both trying to set this. I think this only makes sense as a constructor option. For internal use, you could subclass the module to always provide the option. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/
On Wed Feb 08 16:39:46 2012, autarch@urth.org wrote: Show quoted text
> On Wed, 8 Feb 2012, Douglas Wilson via RT wrote: > > I think this only makes sense as a constructor option.
As in: my $fmt = DateTime::Format::Strptime( zone_map => { PST => '-0800' } );
Subject: Re: [rt.cpan.org #74762] Allow option to define ambiguous timezones
Date: Wed, 8 Feb 2012 20:26:53 -0600 (CST)
To: Douglas Wilson via RT <bug-DateTime-Format-Strptime [...] rt.cpan.org>
From: Dave Rolsky <autarch [...] urth.org>
On Wed, 8 Feb 2012, Douglas Wilson via RT wrote: Show quoted text
> Queue: DateTime-Format-Strptime > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=74762 > > > On Wed Feb 08 16:39:46 2012, autarch@urth.org wrote:
>> On Wed, 8 Feb 2012, Douglas Wilson via RT wrote: >> >> I think this only makes sense as a constructor option.
> > As in: > > my $fmt = DateTime::Format::Strptime( > zone_map => { PST => '-0800' } > );
You're missing a "new", but yes, something like that would make sense, I think. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/
On Wed Feb 08 21:27:04 2012, autarch@urth.org wrote: Show quoted text
> On Wed, 8 Feb 2012, Douglas Wilson via RT wrote: >
> >> I think this only makes sense as a constructor option.
> > > > As in: > > > > my $fmt = DateTime::Format::Strptime( > > zone_map => { PST => '-0800' } > > );
> > You're missing a "new", but yes, something like that would make sense, I > think.
Here's a patch and some tests... :)
Subject: Strptime.diff.txt
--- DateTime-Format-Strptime-1.5000/lib/DateTime/Format/Strptime.pm Sat Oct 16 13:26:44 2010 +++ DateTime-Format-Strptime-1.5001/lib/DateTime/Format/Strptime.pm Fri Feb 10 15:23:03 2012 @@ -8,7 +8,7 @@ use DateTime; use DateTime::Locale; use DateTime::TimeZone; -use Params::Validate qw( validate SCALAR SCALARREF BOOLEAN OBJECT CODEREF ); +use Params::Validate qw( validate SCALAR SCALARREF BOOLEAN OBJECT HASHREF CODEREF ); use Carp; use Exporter; @@ -132,6 +132,7 @@ @_, { pattern => { type => SCALAR | SCALARREF }, time_zone => { type => SCALAR | OBJECT, optional => 1 }, + zone_map => { type => HASHREF, default => {} }, locale => { type => SCALAR | OBJECT, default => 'English' }, on_error => { type => SCALAR | CODEREF, default => 'undef' }, diagnostic => { type => SCALAR, default => 0 }, @@ -343,21 +344,22 @@ } if ($timezone) { + my $tz = $self->{zone_map}{$timezone} || $ZONEMAP{$timezone}; $self->local_croak("I don't recognise the timezone $timezone.") and return undef - unless $ZONEMAP{$timezone}; + unless $tz; $self->local_croak("The timezone '$timezone' is ambiguous.") and return undef - if $ZONEMAP{$timezone} eq 'Ambiguous' + if $tz eq 'Ambiguous' and not( $tz_offset or $tz_olson ); $self->local_croak( "Your timezones ('$tz_offset' and '$timezone') do not match.") and return undef if $tz_offset - and $ZONEMAP{$timezone} ne 'Ambiguous' - and $ZONEMAP{$timezone} != $tz_offset; - $use_timezone = $ZONEMAP{$timezone} - if $ZONEMAP{$timezone} ne 'Ambiguous'; + and $tz ne 'Ambiguous' + and $tz != $tz_offset; + $use_timezone = $tz + if $tz ne 'Ambiguous'; } if ($tz_olson) { @@ -1141,6 +1143,11 @@ string you pass to C<parse_datetime>, then the resulting C<DateTime> will use that time zone. +Some time zones are ambiguous (e.g. PST, EST, EDT). You may specify a +zone_map parameter that specifies a mapping of time zone to offset, e.g.: + + zone_map => { PST => '-0800', EST => '-0600' } + You can optionally use an on_error parameter. This parameter has three valid options:
Subject: 010_myzone.t
#!perl -w # t/010_myzone.t - Custom time zone map use Test::More tests => 6; use DateTime; use DateTime::Format::Strptime; my %zone_map = ( PST => '-0800', EST => '-0500', EDT => '-0400', CST => '-0500', CDT => '-0600', ); # 1-3 test( input => '2009-07-13 11:37:42 PST', output => '2009-07-13 11:37:42 -0800', ); # 4-6 test( input => '2009-07-13 11:37:42 EST', output => '2009-07-13 11:37:42 -0500', ); sub test { my %arg = @_; my $strptime = DateTime::Format::Strptime->new( pattern => $arg{pattern} || '%F %T %Z', locale => $arg{locale} || 'en', diagnostic => $arg{diagnostic} || 0, on_error => $arg{on_error} || 'undef', zone_map => \%zone_map, ); isa_ok( $strptime, 'DateTime::Format::Strptime' ); my $parsed = $strptime->parse_datetime( $arg{input} ); isa_ok( $parsed, 'DateTime' ); is( $parsed->strftime('%Y-%m-%d %H:%M:%S %z'), $arg{output}, 'Input/Output Matches' ); }
On Fri Feb 10 23:28:04 2012, DOUGW wrote: Show quoted text
> On Wed Feb 08 21:27:04 2012, autarch@urth.org wrote:
> > On Wed, 8 Feb 2012, Douglas Wilson via RT wrote: > >
> > >> I think this only makes sense as a constructor option.
> > > > > > As in: > > > > > > my $fmt = DateTime::Format::Strptime( > > > zone_map => { PST => '-0800' } > > > );
> > > > You're missing a "new", but yes, something like that would make sense, I > > think.
> > Here's a patch and some tests... :)
BUMP! Doug's code looks good to me, could we get it merged in please? I've just hit this issue again with the latest clock change with some of our code using this module. Incidentally the documentation for %z and %Z both say "[See note below]" but there doesn't appear to be a note below.