Can DateTime-Format-W3CDTF be updated?
There's a patch for DateTime-Format-W3CDTF on rt.cpan.org that would be great to get into its next release: http://rt.cpan.org/Ticket/Display.html?id=14179 Any chance? ;) Thanks for a great module! -- Mike Mike Schilli m...@perlmeister.com
Re: %p in DateTime::Format::Strptime doesn't match PM
On Tue, 20 Jun 2006, Rick Measham wrote: To work out the 'why', check $p-errmsg: Your am/pm value (PM) does not match your hour (01) So your am/pm value of 'PM' doesn't match the hour 01 as 01 is in the morning. To hand it to you on a platter, you're using the %H specifier in your pattern which is the 24-hour specifier rather than %I which is the 12 hour specifier. Oh my! Thanks for your help. But I've got to tell you, had I seen Your am/pm value (PM) does not match your hour (01), I would have never guessed what it meant. Maybe %H matched a 24-hour value in the AM range, which conflicts with the %p value found (PM). Use %I for 12-hour values. would be easier to understand for the impatient reader :). Thanks again, -- Mike Mike Schilli [EMAIL PROTECTED]
Re: %p in DateTime::Format::Strptime doesn't match PM
On Tue, 20 Jun 2006, Rick Measham wrote: Mike Schilli wrote: Maybe %H matched a 24-hour value in the AM range, which conflicts with the %p value found (PM). Use %I for 12-hour values. would be easier to understand for the impatient reader :). Sure .. I can do that .. though it won't specify %H .. more like: The hour value is in 24-hour time, however the value specified (1) does not match the am/pm value (pm) Hmm, it's more expressive than the previous one, but I'd say that using %I instead of %H is not obvious (even for me, and I've been using your module for a while now), so I think the error message could benefit from having a hint to %I included. -- Mike Mike Schilli [EMAIL PROTECTED]
%p in DateTime::Format::Strptime doesn't match PM
Looks like the %p in the Strptime snippet below doesn't match the PM in the date string. Anyone knows why? use DateTime::Format::Strptime; my $p = DateTime::Format::Strptime-new( pattern = '%d/%b/%Y %H:%M %p', locale = 'en_US', ); my $dt = $p-parse_datetime(21/Jun/2006 01:30 PM); print $dt\n; -- Mike Mike Schilli [EMAIL PROTECTED]
Days between dates FAQ?
Is this the simplest way of determining the days between 3/30 and today?
use DateTime;
my $jf = DateTime-new(year = 2006,
month = 3,
day = 30);
my $ff = DateTime-today();
my $days = 0;
for(my $dt = $jf-clone();
$dt = $ff;
$dt-add(days = 1)
) {
$days++;
}
print $days\n;
I tried the FAQ and the closest question I found there is How can I
calculate the difference in days between dates, but without counting
Saturdays and Sundays?. The answer is marked TODO:
http://datetime.perl.org/index.cgi?FAQSampleCalculations
-- Mike
Mike Schilli
[EMAIL PROTECTED]
Re: Days between dates FAQ?
On Mon, 1 May 2006, Jerrad Pierce wrote: PS Of course, it'd be good if as_list was context sensitive so it could optimize that. ... it'd be even better if there was an obvious way to solve a common task like this. How long would it take the average Perl programmer to a) find DateTime::Event::Recurrence in the DateTime docs and b) understand that the scalar context of a function returns the number of elements? And the lingo isn't even accurate: If as_list() truly returned a list, the result in scalar context would be largely surprising. I guess it returns an array, not a list, right? Probably something like subtract_datetime_absolute_in_days() would be easier to grasp (referring to subtract_datetime_absolute() which does something similar). Or maybe even something like $from-full_days_to($to); would do the trick? -- Mike Mike Schilli [EMAIL PROTECTED]
Leap seconds only in UTC time zone?
From the DateTime documentation, I would have thought that leap seconds apply
to all time zones (except floating ones), but the following code
use DateTime;
for my $time_zone (qw(UTC America/Los_Angeles)) {
my $now = DateTime-new(
year = 1972,
month = 12,
day = 31,
hour = 23,
minute= 59,
second= 0,
time_zone = $time_zone
);
my $later = $now-clone()-add( seconds = 60 );
print $time_zone: , $later-datetime(), \n;
}
prints
UTC: 1972-12-31T23:59:60
America/Los_Angeles: 1973-01-01T00:00:00
and seems to suggest that you get the leap second only in UTC. Is this correct?
-- Mike
Mike Schilli
[EMAIL PROTECTED]
Re: Leap seconds only in UTC time zone?
On Sat, 5 Nov 2005, Mike Schilli wrote:
From the DateTime documentation, I would have thought that leap seconds
apply
to all time zones (except floating ones), but the following code
use DateTime;
for my $time_zone (qw(UTC America/Los_Angeles)) {
my $now = DateTime-new(
year = 1972,
month = 12,
day = 31,
hour = 23,
Argh, please disregard this one. Setting the hour to 15 according to the time
difference will fix it of course. Sorry!
-- Mike
Mike Schilli
[EMAIL PROTECTED]
minute= 59,
second= 0,
time_zone = $time_zone
);
my $later = $now-clone()-add( seconds = 60 );
print $time_zone: , $later-datetime(), \n;
}
prints
UTC: 1972-12-31T23:59:60
America/Los_Angeles: 1973-01-01T00:00:00
and seems to suggest that you get the leap second only in UTC. Is this
correct?
-- Mike
Mike Schilli
[EMAIL PROTECTED]
DateTime documentation example shows error
Looks like this example doesn't work: Leap Seconds and Date Math The presence of leap seconds can cause some strange anomalies in date math. For example, the following is a legal datetime: my $dt = DateTime-new( year = 1971, month = 12, day = 31, hour = 23, minute = 59, second = 60, time_zone = UTC ); It returns undef with DateTime 0.2901 and prints a warning: Invalid second value (60) -- Mike Mike Schilli [EMAIL PROTECTED]
Adding seconds gets stuck
Adding seconds to a date gets stuck when it reaches a leap second:
use DateTime;
my $dt = DateTime-new(
year = 1972,
month = 12,
day = 31,
hour = 23,
minute= 59,
second= 55,
time_zone = UTC);
for(1..10) {
$dt-add( seconds = 1);
print $dt-datetime(), \n;
}
produces
1972-12-31T23:59:56
1972-12-31T23:59:57
1972-12-31T23:59:58
1972-12-31T23:59:59
1972-12-31T23:59:60
1972-12-31T23:59:60
1972-12-31T23:59:60
1972-12-31T23:59:60
1972-12-31T23:59:60
1972-12-31T23:59:60
-- Mike
Mike Schilli
[EMAIL PROTECTED]
DateTime::Format and time zones
Hi DateTime enthusiasts, DateTime::Format::* objects are accepting a 'time_zone' argument, which lets you conveniently set the time zone in the DateTime object returned by parse_datetime(). However, DateTime::Format::Strptime (and other formatters) serve another purpose as well: They're used as output formatters, set via DateTime's set_formatter() method, and controlling the stringification of the DateTime object. Now, regardless what the time_zone setting is in a DateTime's formatter, the stringified representation of it remains the same. That's quite confusing. I think the formatter should either convert the DateTime object's datetime to the formatter's time_zone or the output formatter shouldn't offer a time_zone setting (therefore be different from the parse input formatter which needs it). Here's the status quo, showing that the time_zone setting of the formatter doesn't affect the output. use DateTime; use DateTime::Format::Strptime; my $format1 = new DateTime::Format::Strptime( pattern = %Y/%m/%d %H:%M:%S, time_zone = 'Asia/Tokyo' ); my $format2 = new DateTime::Format::Strptime( pattern = %Y/%m/%d %H:%M:%S, time_zone = 'America/Los_Angeles' ); my $dt = DateTime-new( year = 2006, month = 1, day = 1, hour = 1); # 2006-01-01T01:00:00 print $dt\n; $dt-set_formatter($format1); # 2006/01/01 01:00:00 print $dt\n; $dt-set_formatter($format2); # 2006/01/01 01:00:00 print $dt\n; What do you think? Another thing I found counter-intuitive was that if parse_datetime() is used with a formatter that doesn't have a time zone, it returns a DateTime object, which, if you set its time zone, changes its value: use DateTime; use DateTime::Format::Strptime; my $format = new DateTime::Format::Strptime( pattern = %Y/%m/%d %H:%M:%S, ); my $dt = $format-parse_datetime( 2006/01/01 05:00:00); $dt-set_time_zone(Asia/Tokyo); # Prints 2006-01-01T14:00:00 print $dt\n; Shouldn't parse_datetime() create a DateTime object with a floating time zone in this case? Anyway, great work, guys! -- Mike Mike Schilli [EMAIL PROTECTED]
DateTime::Duration during DST switches
Hey DateTime guys, calculating the time span between two events, one of which is before a daylight saving time switch, and the other one is right after, DateTime shouldn't count the non-existing time, right? But if when calculating the elapsed time between 01:58 and 03:01 on 04/06/2003 (when the DST switch happened at 02:00 local time in the US, forwarding the clock to 03:00), I would expect a 3 minute duration: my $start = DateTime-new( year = 2003, month = 4, day = 6, hour = 1, minute= 58, time_zone = America/Chicago, ); my $finish = DateTime-new( year = 2003, month = 4, day = 6, hour = 3, minute= 01, time_zone = America/Chicago, ); my $duration = $finish - $start; printf %02d:%02d\n, $duration-hours(), $duration-minutes(), \n; Instead, the above code prints 01:03, just like if didn't consider the DST switch. On the other, hand it's well aware of the fact that times between 02:00 and 03:00 are invalid, it rightfully refuses to construct DateTime objects for these times. So why is the duration different? -- Mike Mike Schilli [EMAIL PROTECTED]
Invalid local time for America/Winnipeg
Hey guys, while doing some DateTime calculations, I just stumbled across this weird error: The following snippet produces Invalid local time for the America/Winnipeg timezone while it works for all others: use DateTime; my $dt = DateTime-from_epoch(epoch = 114128); $dt-set_time_zone(America/Winnipeg); $dt-add_duration(DateTime::Duration-new(months = 1)); Any ideas? I'm using the latest DateTime from CPAN, 0.19. -- Mike Mike Schilli [EMAIL PROTECTED]
Re: Invalid local time for America/Winnipeg
Dave Rolsky wrote on 12/19/2003, 12:39 AM:
Attempting to create an invalid time currently causes a fatal error.
This may change in future version of this module.
Gotcha! An eval {} did the trick. Thanks!
--
-- Mike
Mike Schilli
[EMAIL PROTECTED]
