[Announce] DateTime::Format::Strptime 1.0700
This will be hitting your local CPAN mirror shortly. (yes I know I misspelled twilight .. but it's not worth a patch!) Cheers! Rick Measham 1.0700 Sat, 5 Nov 2005 09:44:10 +1100 - The 'Twighlight Zone' release - Mike Schilli pointed out that strings without time zones or constructors without a time zone should be returning a DateTime in the floating time zone rather than UTC. - Jason Bodnar requested greater allowance for time zones in strings .. so I've now added the ability to use an Olson time zone identifier with %O. Note that this is a token specifically added to Strptime and it WILL NOT WORK with DateTime's strftime method.
RE: Time zones?
Hi Jason, Jason Bodnar wrote: > DateTime complains that PST is ambiguous so I tried replacing PST with > 'US/Pacific', 'America/Los_Angeles' and 'PST8PDT' but DateTime says > it doesn't recognise [sic] any of those. So what timezone label will > DateTime accept for Pacific Standard Time? Odd, America/Los_Angeles should work. use strict; use warnings; use DateTime; my $dt = DateTime->now( time_zone => 'America/Los_Angeles'); print $dt; prints 2005-11-04T14:04:52 You may want to include a small test script which demonstrates the error. Hope this helps Ron Hill
RE: Time zones?
Hi Jason,
Jason Bodnar wrote:
> #!/usr/bin/perl
>
> use DateTime::Format::Strptime;
> my $parser = new DateTime::Format::Strptime(pattern => '%d-%b-%Y
> %H:%M %Z', on_error =>
> 'croak'); my $dt = $parser->parse_datetime("30-Oct-2005 01:04
> America/Los_Angeles"); __END__
You are using the %Z as the timezone, I thought that was for
output only. (Rick needs to comment on that)
>
> $ perl test.pl
> I don't recognise the timezone America. at test.pl line 6
>
> Seems to be a problem specifically with Strptime because your example
> worked for me. I guess Strptime doesn't know about the same TZs as
> DateTime.
Re: Time zones?
Thanks for the clarification. I dropped the %Z at the end of my pattern and
put time_zone => 'America/Los_Angeles' in the ctor and everything works fine.
Thanks,
Jason
On Sat, 05 Nov 2005 09:48:55 +1100, Rick Measham wrote
> Jason Bodnar wrote:
> > my $dt = $parser->parse_datetime("30-Oct-2005 01:04 America/Los_Angeles");
>
> On Fri, 4 Nov 2005 14:09:14 -0800, Hill, Ronald wrote
> >my $dt = DateTime->now( time_zone => 'America/Los_Angeles');
>
> You're both talking about completely different things. As per
> previous email, you can't (yet) put an Olson time zone ID in the
> string. Only in the constructor.
>
> Cheers!
> Rick Measham
--
Jason Bodnar
[EMAIL PROTECTED]
http://www.shakabuku.org
UnWired Buyer. The best way to win on eBay. Period.
http://www.unwiredbuyer.com
RE: Time zones?
#!/usr/bin/perl
use DateTime::Format::Strptime;
my $parser = new DateTime::Format::Strptime(pattern => '%d-%b-%Y %H:%M %Z',
on_error => 'croak');
my $dt = $parser->parse_datetime("30-Oct-2005 01:04 America/Los_Angeles");
__END__
$ perl test.pl
I don't recognise the timezone America. at test.pl line 6
Seems to be a problem specifically with Strptime because your example worked
for me. I guess Strptime doesn't know about the same TZs as DateTime.
On Fri, 4 Nov 2005 14:09:14 -0800, Hill, Ronald wrote
> Hi Jason,
>
> Jason Bodnar wrote:
> > DateTime complains that PST is ambiguous so I tried replacing PST with
> > 'US/Pacific', 'America/Los_Angeles' and 'PST8PDT' but DateTime says
> > it doesn't recognise [sic] any of those. So what timezone label will
> > DateTime accept for Pacific Standard Time?
>
> Odd, America/Los_Angeles should work.
>
> use strict;
> use warnings;
> use DateTime;
>
> my $dt = DateTime->now( time_zone => 'America/Los_Angeles');
>
> print $dt;
>
> prints 2005-11-04T14:04:52
>
> You may want to include a small test script
> which demonstrates the error.
>
> Hope this helps
>
> Ron Hill
--
Jason Bodnar
[EMAIL PROTECTED]
http://www.shakabuku.org
UnWired Buyer. The best way to win on eBay. Period.
http://www.unwiredbuyer.com
Time zones?
I'm using DateTime and DateTime::Format::Strptime to convert some third-party data into MySQL-compatible formats and changing the time zone to GMT. The data had PDT as the time zone until this past weekend when Daylight Savings Time ended and now has PST. DateTime complains that PST is ambiguous so I tried replacing PST with 'US/Pacific', 'America/Los_Angeles' and 'PST8PDT' but DateTime says it doesn't recognise [sic] any of those. So what timezone label will DateTime accept for Pacific Standard Time? -- Jason Bodnar [EMAIL PROTECTED] http://www.shakabuku.org UnWired Buyer. The best way to win on eBay. Period. http://www.unwiredbuyer.com
Re: DateTime::Format and time zones
On Thu, Nov 03, 2005 at 01:52:39PM -0800, Mike Schilli wrote: > Shouldn't parse_datetime() create a DateTime object with a floating time zone > in this case? I agree. I ran up against a similar issue yesterday using DateTime::Format::DateManip because it sets to the local timezone (as determined by Date::Manip). For example, I have a web form where events are created. A time and location (where the event is located) need to be entered. When the event date is entered it's assumed to be a time local to the location of the event. So I want to accept a floating time and then set its timezone based on the timezone of the location. So if my server is in US/Pacific: use DateTime::Format::DateManip; my $event_time = 'Monday at 9am'; my $event_location = 'America/Chicago'; my $dt = DateTime::Format::DateManip->parse_datetime($event_time); print "Time = $dt\n"; $dt->set_time_zone( $event_location ); print "Time = $dt\n"; returns: Time = 2005-10-31T09:00:00 Time = 2005-10-31T11:00:00 which might make some people in Chicago a bit upset when they show up late to the event. My solution was to set a floating time first, but seems like by default the parsers should set a floating time zone. my $dt = DateTime::Format::DateManip->parse_datetime($event_time); $dt->set_time_zone( 'floating' ); By the way, I'm open to suggestion on better ways to parse free-form time entries. -- Bill Moseley [EMAIL PROTECTED]
[Fwd: Possible Bug in Date::ICal 1.72]
Anybody know who is currently maintaning this module? I hope it's not me.
Original Message
Subject: Possible Bug in Date::ICal 1.72
Date: Thu, 3 Nov 2005 21:15:49 -0500 (EST)
From: Joshua Baer <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Rich Bowen:
My name is Joshua Baer, and I've been using your Date::ICal perl module to
produce RFC iCalendar formatted date-time fields. This module has been a big
help in speeding the development of my project, which produces an iCalendar
input file for the Oracle Calendar suite from an in-house calendar format.
The bug concerns the formatting of date-time iCal strings. When a Date::ICal
object is created which is supposed ends up representing midnight UTC on any
given date, the returned iCal string does not seem to comply with RFC 2445.
Example: (i'm in EST -5 GMT)
my $icalstrone = Date::ICal->new(year => 1981, month => 12, day => 1,
hour =>
19)->ical;
print $icalstrone;
yields:
19811202Z
---
my $icalstrtwo = Date::ICal->new(epoch => 1131321600)->ical;
print $icalstrtwo;
yields:
20051107Z
According to section 4.3.5 of RFC 2445 a properly formatted date-time
string for
midnight gmt utc would look like the following:
19811202T00Z
20051107T00Z
>From RFC 2445:
"
date-time = date "T" time
The text format is a concatenation of the "date", followed by the LATIN
CAPITAL
LETTER T character (US-ASCII decimal 84) time designator, followed by the
"time" format."
Furthermore, the "time" format expresses midnight with the string
'00' not a
null string (Section 4.3.12), and the "date" format does not allow a
trailing
"Z" character. (Section 4.3.4) So, the Date::ICal->ical sub does not produce
output compliant with either "date-time", "date", or "time" formatted
fields as
they are defined in the RFC in this particular case.
I took a look at the source Date::ICal, ICal.pm and found that simple
fix will
bring the module into compliance. The following are lines 287 through 294 in
ICal.pm version 1.72:
if ( $self->hour || $self->min || $self->sec ) {
$ical =
sprintf( '%04d%02d%02dT%02d%02d%02dZ', $self->year,
$self->month,
$self->day, $self->hour, $self->minute, $self->second );
} else {
$ical =
sprintf( '%04d%02d%02dZ', $self->year, $self->month,
$self->day );
}
If the second sprintf statement (line 293) is changed to the following, the
problem should be fixed, at least if the desired output is in the
"date-time"
format.
sprintf( '%04d%02d%02dT00Z', $self->year, $self->month,
$self->day );
Like I said before, using this module has been a pleasure, and if I had been
using any other Calendaring Suite than Oracle, there probably wouldn't have
been a problem. Unfortunately Oracle is extremely picky about which
iCalendar
formatted files it chooses to import, and which ones it chooses to reject
without any description whatsoever as to why the import failed. I suppose it
boils down to this: Oracle didn't like the non-compliant iCal output from
Date::iCal, and I just had the time of my life trying to debug hundreds
of iCal
records.
Thanks again for your work! Hopefully, this fix will save a couple of people
some time somewhere in the future. If you have any comments or
questions, I'm
available at [EMAIL PROTECTED]
Regards,
Joshua
--
Rich Bowen
[EMAIL PROTECTED]
