houseabsolute / datetime.pm Goto Github PK
View Code? Open in Web Editor NEWA date and time object for Perl
Home Page: https://metacpan.org/release/DateTime/
License: Other
datetime.pm's People
Contributors
Stargazers
Watchers
Forkers
markstos rjbs rsrchboy stvleung haarg jmacdotorg karenetheridge 1nickt sewi-cpan ovid chansen viviparous nrdvana book skington waterkip haukex nebulous peternewman arc bigpresh yahermann speck-drum grinnz hotbrainy dracos pghmcfc wolfsage jkeenan manwar hurricup gaiederer markov2 n1vux 17hats saurabhhack123 gimme00 clayne atoomic worthmine kes777 modestgoblin d-c-d hatsuseno sisyphus sysfce2 bombsimondatetime.pm's Issues
Handling dates
I use DateTime for all kinds of date/time handling.
Sometimes I have to deal with dates, year/month/day, without time. DateTime can handle this. Hoewever, as far as DateTime concerns, a date without time is just a date with time 00:00:00. So I can not tell from the DateTime object that it was created to represent a date only.
After reading the docs and the wiki I started to wonder whether I'm overlooking something trivial. Is it possible for DateTime to represent a date without time and distinguish this from a date with time 00:00:00?
Thanks for the great module.
local_rdn_values at leap seconds
Migrated from rt.cpan.org #71275 (status was 'new')
Requestors:
From [email protected] on 2011-09-27 13:01:33:
(This is what I really wanted to investigate that led to me discovering
the preceding two bugs about timezones and leap seconds.)
For a time at a leap second, the local_rd_values that DateTime supplies
are problematic: they're generated inconsistently, and in the general
case result in ambiguity. For reference, here's what the related
utc_rd_values does:
$ perl -MDateTime -lwe '$dt=DateTime->new(year=>2008,month=>12,day=>31,hour=>23,minute=>59,second=>60, time_zone=>"UTC"); print $dt; print join",",$dt->utc_rd_values'
2008-12-31T23:59:60
733407,86400,0
It returns a seconds-of-day value of 86400, which of course can't occur in
a normal day. This uniquely identifies the leap second, and puts it in
its proper numerical place relative to all the other seconds of the day.
But that can only work when the leap second occurs right at the end of the
day, which it does in UTC but in the general case doesn't in a timezone.
Suppose we have a timezone offset of an hour:
$ perl -MDateTime -lwe '$dt=DateTime->new(year=>2008,month=>12,day=>31,hour=>23,minute=>59,second=>60, time_zone=>"UTC"); $dt->set_time_zone("+01:00"); print $dt; print join",",$dt->local_rd_values'
2009-01-01T00:59:60
733408,3600,0
$ perl -MDateTime -lwe '$dt=DateTime->new(year=>2009,month=>1,day=>1,hour=>0,minute=>0,second=>0, time_zone=>"UTC"); $dt->set_time_zone("+01:00"); print $dt; print join",",$dt->local_rd_values'
2009-01-01T01:00:00
733408,3600,0
Stringification shows the correct broken-down time of 00:59:60.
The local_rd_values show the correct day, and 3600 seconds into that day,
which is understandable since the preceding second (00:59:59) was actually
3559 seconds into the day. However, 3600 is the same seconds-of-day
value that one would normally expect for the time 01:00:00, and indeed
the following second does show the same seconds-of-day value despite
being a different time. So the local_rd_values result is ambiguous.
It's also calculated inconsistently. For a timezone offset of zero I
can get two different results, depending on whether the timezone is_utc:
$ perl -MDateTime -lwe '$dt=DateTime->new(year=>2008,month=>12,day=>31,hour=>23,minute=>59,second=>60, time_zone=>"UTC"); $dt->set_time_zone("UTC"); print $dt; print join",",$dt->local_rd_values'
2008-12-31T23:59:60
733407,86400,0
$ perl -MDateTime::TimeZone::SystemV -MDateTime -lwe '$dt=DateTime->new(year=>2008,month=>12,day=>31,hour=>23,minute=>59,second=>60, time_zone=>"UTC"); $dt->set_time_zone(DateTime::TimeZone::SystemV->new("UTC0")); print $dt; print join",",$dt->local_rd_values'
2009-01-01T23:59:60
733408,0,0
For the is_utc zone, local_rd_values returns the correct day and the same
distinctive (but irregular) seconds-since-day value as utc_rd_values.
For the non-is_utc zone, which otherwise behaves identically,
local_rd_values returns (as for the non-zero offsets) a regular-looking
seconds-of-day value that appears to identify the second following the
leap second. In this case that also involves showing the wrong day.
The Europe/London zone, which is not generally equivalent to UTC but
happens to have a zero offset at that time, also produces what looks
like the first second of the next day.
DateTime doesn't document what utc_rd_values and local_rd_values are
meant to do around a leap second. It does say they're meant for other
modules to be able to extract the time represented by the object. To have
local_rd_values return an apparently-regular value for the leap second,
ambiguous with the following second, defeats this purpose, because its
value doesn't fully identify the local time represented by the object.
Since providing seconds-of-day = 86400 only works at the very end of
the day, that's not a solution either. For local_rd_values to be fully
useful, it's going to need some other behaviour.
For the purposes of timezones, in the modern era timezones are all
UTC-compatible by virtue of using only offsets of integral minutes, so
usually the number of seconds into the minute doesn't matter. Timezones
therefore usually want to treat a leap second like the preceding second
(xx:xx:59). It would be convenient if leap seconds were indicated by
having seconds-of-day the same as it was for the preceding second and
letting the nanoseconds-of-second value exceed 10^9. This trick has
been proposed for struct timeval/timespec in some situations, and it
doesn't run into 32-bit trouble.
-zefram
%Y and %C don't zero-pad short centuries like %F does
I'm using DateTime 1.26 but it behaves identically in 1.49.
I had a surprising formatting problem when I had a date with an incorrect year (206 instead of 2016). The year came out as 206 instead of 0206 when formatted with %C and %Y under strftime.
The docs say %C is "The century number (year/100) as a 2-digit integer."
%Y is "The year as a decimal number including the century."
%F is "Equivalent to %Y-%m-%d (the ISO 8601 date format)" but that is not the case as the code below shows.
my $normal_year = DateTime->new(
year => 2016,
month => 5,
day => 8,
);
my $short_year = DateTime->new(
year => 206,
month => 5,
day => 8,
);
my @formats = qw( %Y-%m-%d %C%y-%m-%d %F );
for my $dt ( $normal_year, $short_year ) {
for my $fmt ( @formats ) {
say $dt->strftime( $fmt ), ' with ', $fmt;
}
}
gives this output
2016-05-08 with %Y-%m-%d
2016-05-08 with %C%y-%m-%d
2016-05-08 with %F
206-05-08 with %Y-%m-%d
206-05-08 with %C%y-%m-%d
0206-05-08 with %F
Support separator in datetime() accessor?
I, very often, find myself writing e.g. $dt->ymd . ' ' . $dt->hms to get a readable date and time; I know I'm very much not alone in that.
$dt->datetime gives almost what I'd need, but in the ISO-standard format e.g. YYYY-MM-DDTHH:MM::SS, which is a bit ugly and not user-friendly.
What I would really, really like would be the ability to pass a separator character to override the "T" - e.g. $dt->datetime(' ') (which would be somewhat consistent with how e.g. $dt->hms lets you specify which character should be used to join hours, minutes and seconds).
Or, alternatively, a $dt->ymd_hms() method which would default to a space - but it's probably simpler and cleaner not to add another method when what it would do could be trivially done as above.
If I raised a PR doing this, would it be likely to be accepted, or is this not a desired feature in core DateTime? We could of course subclass it and do it ourselves, but it seems, to me, like something that would be widely useful in DateTime itself. Opinions welcome!
Please bring back 5.8.1 minperl
Migrated from rt.cpan.org #117959 (status was 'open')
Requestors:
From [email protected] (@ribasushi) on 2016-09-19 16:08:54:
I have been testing this dist on 5.8.3 forever and it has always passed tests and the tests of the downstream dependency, right until you bumped the versions. I also sometimes test locally on 5.8.1: though I have not done this in a while, and a spurious Test::NoWarnings-based failure has crept in.
I never got the chance to setup a travis=>metabase backend, thus you never saw the reports.
The most recent 5.8.3 pass took place 4 days ago: https://travis-ci.org/ribasushi/dbix-class/jobs/160201358#L1119
TO_JSON
Migrated from rt.cpan.org #117799 (status was 'open')
Requestors:
From [email protected] (@nebulous) on 2016-09-12 19:16:00:
Often I will subclass (or yes, sometimes monkeypatch like an idiot), DateTime in order to add a TO_JSON method:
sub TO_JSON { shift->iso8601.'Z' }
Would it be possible/advisable to add said method to DateTime itself? If so I'll be happy to submit a PR with tests.
day duration leads to invalid local time
Migrated from rt.cpan.org #87769 (status was 'new')
Requestors:
From [email protected] on 2013-08-11 16:02:54:
With DateTime-1.03:
$dt0 = DateTime->new(year => 2013, month => 3, day => 30, hour => 1, time_zone => "Europe/London");
$dt1 = DateTime->new(year => 2013, month => 3, day => 31, hour => 2, time_zone => "Europe/London");
$dur = $dt1 - $dt0;
# $dur is 1 day
print $dt0 + $dur;
# => Invalid local time for date in time zone: Europe/London
As with the previous bug, this should be an easy case for duration
arithmetic, because the duration is being used additively to represent
the same calendar interval from which it was generated. $dur is
sane in describing the interval as 1 day; the two times are exactly 24
hours apart. However, adding that day onto $dt0 requires accounting for
the DST transition at the target time. ->add_duration is not in fact
doing what ->subtract_datetime assumed it would, and so the addition
and subtraction operations are mismatched.
-zefram
Simple scalars are insufficient for DateTime math
Migrated from rt.cpan.org #41375 (status was 'open')
Requestors:
From [email protected] on 2008-12-02 14:09:39:
Hi,
The following applies to DateTime 0.45 on Perl 5.10.0 (Win32).
This is wrong:
$ perl -mDateTime -e "print ((DateTime->new(year => 1970,
time_zone => 'UTC')->subtract_datetime_absolute(DateTime->new(year
=> 1583, time_zone => 'UTC')))->seconds)"
12212553600
Conversely:
$ perl -mDateTime -e "print DateTime->new(year => 1583,
time_zone => 'UTC')->add(seconds=>12212553600)"
1582-12-31T23:59:59
$ perl -mDateTime -mMath::BigInt -e "print DateTime->new(year
=> 1583,time_zone=>'UTC')->add(seconds =>
Math::BigInt->new('12212553600'))"
The 'seconds' parameter ("12212553600") to DateTime::Duration::new was a
'hashref object', which is not one of the allowed types: scalar at
C:/strawberry/perl/site/lib/DateTime/Duration.pm line 26
DateTime::Duration::new(undef, 'seconds',
'Math::BigInt=HASH(0x1babaa4)'
) called at C:/strawberry/perl/site/lib/DateTime.pm line 1519
DateTime::add('DateTime=HASH(0x3a224)', 'seconds',
'Math::BigInt=HASH(0x1babaa4)') called at -e line 1
As a work-around, my code has to deal with three separate cases:
- Prior to 1972 - before leap seconds were introduced, so convert delta
seconds > 232 to delta weeks and days < 232 (so far). - 1972 to 6 months from now - delta seconds fits in a 32 bit integer
- More than 6 months from now - leap seconds are unknown, so delta
seconds are uncertain, might as well convert to delta weeks and days.
^^^ Not having to deal with this sort of thing is the reason one uses a
date library in the first place. DateTime is otherwise an excellent module.
--
Andy Switala
Allow arbitrary method output in CLDR formats
Migrated from rt.cpan.org #49767 (status was 'stalled')
Requestors:
From [email protected] on 2009-09-16 18:42:33:
Hello again,
Last one I promise :)
Just FYI: I am filing this rt under DateTime::Locale instead DateTime
since ::Locale specifies formats, let me know if I should re-file under
DateTime (or if this simply won't be implemented), thanks.
strftime() has %s for 'The number of seconds since the epoch.'
Also it supported %{epoch} to have it call the DT method "epoch".
I can't seem to find an equivalent way to do 'The number of seconds
since the epoch.' with format_cldr()
$ perl -MDateTime -le 'print DateTime->now()->strftime("%B %{day}, %Y
%{hour_12}:%M:%S %p %{time_zone_long_name} == %s");'
September 16, 2009 6:24:23 PM UTC == 1253125463
$ perl -MDateTime -le 'print DateTime->now()->strftime("%B %{day}, %Y
%{hour_12}:%M:%S %p %{time_zone_long_name} == %{epoch}");'
September 16, 2009 6:24:33 PM UTC == 1253125473
$ perl -MDateTime -le 'print DateTime->now()->format_cldr("MMMM d, y
h:mm:ss a z == ???");'
September 16, 2009 6:24:40 PM UTC == ???
Is a CLDR %s equivalent currently available and I just missed it? (If so
what did I miss?)
If not: how [im]possible/[un]likley is it to be added?
DateTime::Duration::add() broken since 1.37
DateTime::Duration:add() does not work since DateTime-1.37:
$ perl -Ilib -MDateTime::Duration -e '$a=$b=DateTime::Duration->new(hours=>1, minutes=>0); $a->add($b)'
Expected a hash or hash reference but got a single object argument
adding extremely large number of days fails (related to leap years)
Migrated from rt.cpan.org #97046 (status was 'open')
Requestors:
From [email protected] (@kmx) on 2014-07-08 08:11:27:
Here is a failing code:
use DateTime;
my $DAY_ONE = DateTime->new(year => 0, month => 1, day => 1);
warn $DAY_ONE->clone->add(days => 268526343)->ymd, "\n"; # 735200-02-27
warn $DAY_ONE->clone->add(days => 268526344)->ymd, "\n"; # 735200-02-28
warn eval { $DAY_ONE->clone->add(days => 268526345)->ymd }; # FAILS (should be 735200-02-29)
warn $DAY_ONE->clone->add(days => 268526346)->ymd, "\n"; # 735200-03-01
warn $DAY_ONE->clone->add(days => 268526347)->ymd, "\n"; # 735200-03-02the failure is: Invalid day of month (day = 30 - month = 2 - year = 735200)
I am using: perl 5.18.2 (MSWin32 / x86) + DateTime 1.10
--
kmx
last_day_of_month suggestion
While last_day_of_month is available as a constructor, there are times when I need to know the last day of the current month stored in the DateTime object, and constructing a new object has higher overhead than simply calculating it. While DateTime performs the calculation internally, it is not exposed to users of the class, except in the form of the constructor.
Time::Piece offers this calculation as $tp->month_last_day(). Following the same naming convention, I'd like to propose the following code addition to DateTime.pm:
sub month_last_day {
Carp::carp('month_last_day() is a read-only accessor') if @_ > 1;
return $_[0]->_month_length( $_[0]->{local_c}{year}, $_[0]->{local_c}{month} );
}
Comparison takes long on dates over 2036
When you use a date after 2036, the DateTime::_compare() gets called very often. This is best visible when the year is very large. The program below which makes 100,000 calls to _compare. It does behave timely without time_zone parameter.
#!/usr/bin/perl
use strict;
use warnings;
use DateTime;
use Time::HiRes qw(time);
my $dt1 = DateTime->new(year => 9999, month => 1, day => 1);
my $dt2 = DateTime->new(year => 2019, month => 5, day => 28, time_zone => 'Europe/London');
my $start = time;
my $x = $dt1 < $dt2 ? $dt1 : $dt2;
my $elapse = sprintf "%dms", (time - $start)*1000;
warn "$elapse: $x\n";DateTime::Duration shouldn't allow non-integer multiplication
Migrated from rt.cpan.org #117866 (status was 'new')
Requestors:
From [email protected] on 2016-09-15 16:06:05:
Multiplying a DateTime::Duration object by a non integer can lead to objects with e.g. 1.5 minutes and 30 seconds, which DateTime::Format::Duration will helpfully render as "1:30"
After discussion with DROLSKY the suggestion was that DateTime::Duration objects probably should die if a non-integer multiplication is attempted.
See example at http://stackoverflow.com/questions/39499424/adding-mmss-times-dividing-them-and-printing-the-average/39504609#39504609
minutes offset broken at leap second
Migrated from rt.cpan.org #71274 (status was 'open')
Requestors:
From [email protected] on 2011-09-27 12:11:56:
$ perl -MDateTime -lwe '$dt=DateTime->new(year=>2008,month=>12,day=>31,hour=>23,minute=>59,second=>60, time_zone=>"UTC"); $dt->set_time_zone("+00:05:00"); print $dt'
2009-01-01T23:59:60
$ perl -MDateTime -lwe '$dt=DateTime->new(year=>2008,month=>12,day=>31,hour=>23,minute=>59,second=>60, time_zone=>"UTC"); $dt->set_time_zone("-00:05:00"); print $dt'
2008-12-31T22:59:60
Only happens for a time in a leap second. With a +ve offset, the
minutes part of the offset is completely ignored. With a -ve offset,
any non-zero number of minutes in the offset has the effect of a 1
hour (negative) offset. Hours added onto this behave correctly.
Timezone offsets that are integral multiples of minutes have perfectly
well defined behaviour around leap seconds, when you're looking at
broken-down hh:mm:ss time-of-day.
-zefram
today() fails when 00:00 is not valid in local time zone
Migrated from rt.cpan.org #104646 (status was 'stalled')
Requestors:
From [email protected] on 2015-05-23 23:18:09:
Some time zones, such as Brazil, do the daylight saving time shift at midnight, so 00:00::00 is not a valid time on the day that DST is entered. On these days, the first second of the day is 01:00:00.
Thus, when today() tries to truncate to the current day, it fails with the "Invalid local time for date in time zone" error message.
Equivalent code, using the day of the DST change time for Brazil:
$d = DateTime->new( year => 2014, month => 10, day => 19, time_zone => 'America/Sao_Paulo')The documentation correctly notes that some times are invalid in some time zones, but having today() fail as well is somewhat unexpected. It can cause obscure failures for code that was running fine on any other day.
This is a tricky one. At minimum, this should be noted in the documentation.
One could argue that today() really means "the first valid moment of the given day", in which case the above example should return 2014-10-19T01:00:00. On the other hand, this may cause surprises for developers that assume that today() will always return a DateTime that's truncated to the day, with all smaller components set to zero.
Another exhausting alternative is to rework the whole DateTime system to allow for a "precision" for each DateTime, and consider all components smaller than the given precision to be undefined rather than zero. However, this is a large behavioral change to a key module, which would add to the trickiness.
I'm not sure what the best course is for this one...I ended up hacking a local safe_today() method that caught for the "Invalid local time" exception and moved the time one hour in the future.
Support %- variant for strftime
I just found out that you can use %- to strip leading zeros, e.g.
$ date +%Y/%-m/%d
2019/1/16
Unfortunately, this is not supported by DateTime::Format::Strptime:
use DateTime::Format::Strptime qw(strftime);
my $date = DateTime::Format::Strptime->new(
pattern => "%Y/%-m/%d",
on_error => "croak",
);
my $p = $date->parse_datetime("2015/5/30");
print strftime("%F", $p), "\n" if $p;
"Invalid local time" exception leaves object instance in dirty state.
Steps to reproduce:
- Initialize valid datetime.
my $when = DateTime->new(
'time_zone' => 'Asia/Damascus',
'year' => 2018,
'month' => 3,
'day' => 1
);- Hit nonexistent hour exception.
eval { $when->add( 'days' => 29 ) };
say $@;
# Invalid local time for date in time zone: Asia/Damascus- Check object state. It looks like everything is fine. Object has pre-exception values.
say $when;
# 2018-03-01T00:00:00- But any operation on it now produces weird results.
$when->add( 'days' => 1 );
say $when;
# 2018-03-31T00:00:00(expected value is 2018-03-02T00:00:00)
So when nonexistent hour exception was captured object did not revert cleanly to last valid state despite that it shows like it did.
Expected behavior:
Object returning to state that it had before disallowed add() operation.
Nice to have:
Some flag in add/subtract methods that will produce DWIM result like this:
2018-03-01T00:00:00 Asia/Damascus + 28 days = 2018-03-29T00:00:00
2018-03-01T00:00:00 Asia/Damascus + 29 days = 2018-03-30T01:00:00 # produced without exception
2018-03-01T00:00:00 Asia/Damascus + 30 days = 2018-03-31T00:00:00
Adding hours is very inconvenient, because:
2018-03-01T00:00:00 Asia/Damascus + 29*24 hours = 2018-03-30T01:00:00 # does not throw
2018-03-01T00:00:00 Asia/Damascus + 30*24 hours = 2018-03-31T01:00:00 # meh, now we have 1 hour drift
Wrong (?) values after substraction
Substracting one date from another, I see some ambiguous result. Have a look at the code:
my $dt1 = DateTime->new( year => 2000, month => 3, day => 5, ); my $dt2 = DateTime->new( year => 2000, month => 3, day => 25, ); my $duration = $dt2 - $dt1; print $duration->days; # the result is 6!
I get '6' instead of 20, but getting days via function '$duration->in_units' works well, as well as '$duration->delta_days'. May be I'm missing something but such result looks as a bug.
DateTime problem finding local timezone with strawberry perl 5.20.2?
Migrated from rt.cpan.org #103274 (status was 'stalled')
Requestors:
From [email protected] on 2015-04-02 17:34:46:
Relevants:
Perl: Strawberry 5.20.2
DateTime: 1.18
OS: Win7sp2
Problem: Win7sp2 clients with strawberry perl 5.20.2 receiving error
"cannot determine local timezone" when invoking DateTime->now(time_zone =>
'local').
Comparisons: I am running strawberry perl 5.20.1 with the same DateTime
module version and the same OS and not seeing this problem. I've checked
the following places for inconsistencies in timezone reporting:
- Time zone listed in "Time Zone settings" in "Date and Time" dialog
- all timezone settings in registry at
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInfor
mation\
but I can't find any differences between the OSes except the version of
strawberry perl.
If it matters at all, the localtime function works fine.
Derek
Comparison of two DT objects with nanoseconds sometimes fails
Migrated from rt.cpan.org #53942 (status was 'open')
Requestors:
From [email protected] (@maros) on 2010-01-23 10:41:07:
Hi,
for quite a while I have been observing some weird behavior in the
DateTime::Format::CLDR test suite which most likely originates from
DateTime.
I have written a test case
(http://cpansearch.perl.org/src/MAROS/DateTime-Format-CLDR-1.10/t/011_nanosecond.t
and
http://cpansearch.perl.org/src/MAROS/DateTime-Format-CLDR-1.10/t/lib/testlib.pm)
which generates a DateTime object with nanoseconds, prints it out,
parses the output, returns a new DateTime object and then finally
compares the two objects (via DateTime->compare_ignore_floating).
However this test sometimes fails (according to cpan testers - however
I have never experienced such a test failure myself). The stringified DT
objects look exactly the same, but nonetheless compare_ignore_floating
returns false.
Here are some reported test failures:
http://www.cpantesters.org/cpan/report/6711070
http://www.cpantesters.org/cpan/report/5583764
http://www.cpantesters.org/cpan/report/5373996
http://www.cpantesters.org/cpan/report/5374015
So far I was not able to narrow the problem down to a certain OS/Perl
version/32-64bit/DateTime version/DT::Format::CLDR version ...
For now I'd suggest adding the following test to DateTime' 07compare test:
# sub-second equals
{
my $date1 = DateTime->new( year => 2000, month => 10, day => 24,
hour => 12, minute => 0, second => 0,
nanosecond => 10000,
);
my $date2 = DateTime->new( year => 2000, month => 10, day => 24,
hour => 12, minute => 0, second => 0,
nanosecond => 10000,
);
is( DateTime->compare( $date1, $date2 ), 0, 'Comparison with
floating time (cmp)' );
is( ($date1 <=> $date2), 0, 'Comparison with floating time (<=>)' );
is( ($date1 cmp $date2), 0, 'Comparison with floating time (cmp)' );
is( DateTime->compare_ignore_floating($date1, $date2), 0,
'Comparison with compare_ignore_floating (cmp)' );
}Cheers
Maros
Malformed carp call on line 2035
I am getting errors trying to use the DateTime.pm 1.43 because of line 2035 (and 2036), which are:
carp 'You passed a locale to the set() method.'
. ' You should use set_locale() instead, as using set() may alter the local time near a DST boundary.';
The errors are:
String found where operator expected at C:/Internet/Perl64/site/lib/DATETIME.pm line 2035, near "carp 'You passed a locale to the set() method.'"
(Do you need to predeclare carp?)
syntax error at C:/Internet/Perl64/site/lib/DATETIME.pm line 2035, near "carp 'You passed a locale to the set() method.'"
All other calls to carp in DateTime.pm look like "carp::carp('text')" or "carp::croak('text')".
$dt->set_time_zone breaks EPIC Debugger
Migrated from rt.cpan.org #78670 (status was 'stalled')
Requestors:
From [email protected] on 2012-07-30 16:10:13:
Hello,
I'm having problems while debugging my program using the following
configuration:
- Windows 7 64 bits
- ActivePerl v5.14.2 for MSWin32-x64-multi-thread
- Eclipse SDK Version: 4.2.0 Build id:
I20120608-1400 - EPIC - Eclipse Perl Integration Version: 0.6.44
- PadWalker Perl Module Version: 1.94
- DateTime Perl Module Version: 0.76
- DateTime-TimeZone Version: 1.46
I'm able to see and trace my variables until I use the DateTime Perl Module:
sub gensqlscript
{
use DateTime;
my $dt = DateTime->now;
$dt->set_time_zone( 'America/Chicago' );
print OUT "/****** Object: StoredProcedure
[dbo].[$sp_hash{$x}{'Nombre'}] Script Date: ".$dt->mdy('/')."
".$dt->hms." ******/\n";
.
.
.
}```
After executing the $dt->set_time_zone( 'America/Chicago' ); line the
debbuger stops working and shows this message in Eclipse's Variable view:
"An error occurred while dumping array content; contents of the Variables
view may become invalid".
The log file of Eclipse shows this error:
SESSION 2012-07-30 10:29:40.675
eclipse.buildId=I20120608-1400
java.version=1.7.0_05
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86_64
!ENTRY org.epic.debug 4 0 2012-07-30 10:33:16.737
!MESSAGE Debug Error
!STACK 0
java.lang.NumberFormatException: For input string: "Use of uninitialized
value in sprintf at C:/Perl64/site/lib/DateTime.pm line 766, line 1.
at C:/Perl64/site/lib/DateTime.pm line 766, line 1.
DateTime::ymd('DateTime=HASH(0x49f85a0)', '-') called at
C:/Perl64/site/lib/DateTime.pm line 861
DateTime::iso8601('DateTime=HASH(0x49f85a0)') called at
C:/Perl64/site/lib/DateTime.pm line 842
DateTime::_stringify('DateTime=HASH(0x49f85a0)', undef, '') called at
C:/Users/lcastillo/workspace/.metadata/.plugins/org.epic.debug/
dumpvar_epic.pm line 177
dumpvar_epic::_dump_entity('local_start_datetime', 'REF(0x49f5fa8)') called
at C:/Users/lcastillo/workspace/.metadata/.plugins/org.epic.debug/
dumpvar_epic.pm line 208
dumpvar_epic::_dump_keys('DateTime::TimeZone::OlsonDB::Observance=HASH(0x4b4fea0)',
- called at C:/Users/lcastillo/workspace/.metadata/.plugins/org.epic.debug/
dumpvar_epic.pm line 56
dumpvar_epic::dump_hash('DateTime::TimeZone::OlsonDB::Observance=HASH(0x4b4fea0)')
called at C:/Users/lcastillo/workspace/.metadata/.plugins/org.epic.debug/
dumpvar_epic.pm line 73
dumpvar_epic::dump_hash_expr(0, '${$h->{'$last_observance'}}\x{a}')
called at (eval
10695)[C:/Users/lcastillo/workspace/.metadata/.plugins/org.epic.debug/
perl5db.pl:640] line 13
eval '';
my $subref = \&dumpvar_epic::dump_hash_expr;
my $savout = select($DB::OUT);
my$savbuf = $ "
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at org.epic.debug.db.DumpedEntityReader.token(DumpedEntityReader.java:48)
at
org.epic.debug.db.DumpedEntityReader.nextEntity(DumpedEntityReader.java:37)
at org.epic.debug.db.HashValue.parseHashContent(HashValue.java:49)
at org.epic.debug.db.HashValue.(HashValue.java:25)
at org.epic.debug.db.PerlVariable.getValue(PerlVariable.java:118)
at org.epic.debug.db.StackFrame.rememberVariables(StackFrame.java:386)
at org.epic.debug.db.StackFrame.getVariables(StackFrame.java:193)
at
org.eclipse.debug.internal.ui.model.elements.StackFrameContentProvider.getAllChildren(StackFrameContentProvider.java:51)
at
org.eclipse.debug.internal.ui.model.elements.StackFrameContentProvider.getChildCount(StackFrameContentProvider.java:28)
at
org.eclipse.debug.internal.ui.model.elements.ElementContentProvider.retrieveChildCount(ElementContentProvider.java:114)
at
org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$2.run(ElementContentProvider.java:63)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
What I'm doing wrong?
Is it valid to call $dt = DateTime->now; and then $dt->set_time_zone(
'America/Chicago' ); same error happens if I use the following :
use DateTime;
my $dt = DateTime->now( time_zone => 'America/Chicago' );
I "Solved" this problem with the debugger temporarily using
use DateTime;
my $dt = DateTime->now( time_zone => 'floating' );
________________________________
Luis A. Castillo Pacheco
Extension to iso8601() to include time zone?
I need to write ISO8601 datetime strings in JSON messages being passed between multiple applications with multiple languages. I need to include time zone offset information to avoid ambiguous timestamps.
I note the following difficulties:
-
DateTime's `iso8601' method does not include time zone (as documented) -
I can append time zone by doing something like:
$dt->iso8601 . $dt->strftime('%z')this gives something like
2017-08-09T15:17:28-0400. Unfortunately, this is not parseable byDateTime::Format::ISO8601, as it strictly needs a colon (-04:00) (this has been patched, but not released as far as I can tell; see https://rt.cpan.org/Public/Bug/Display.html?id=108082). -
DateTime::Format::ISO8601does not have aformat_datetimemethod. This makes it unsuitable to be used as a formatter that can be passed to$dt->set_formatter()
Would you be open to a patch to DateTime that would add an option to the iso8601 method that would include time zone offset?
- If the offset is zero (UTC), append
Z - Otherwise, append in the form
+hh:mmor-hh:mm
Example:
$dt->iso8601 # "2017-08-09T15:17:28" (current format)
$dt->iso8601(1) # "2017-08-09T15:17:28-04:00" (with offset)
This would not affect any existing code, because the current iso8601 method does not accept any arguments.
set_formatter() failures introduced in DateTime-1.37
I'm seeing this in formerly-working code (heavy with Moose and other modules) after upgrading DateTime. Interestingly enough if the below snippet is placed in a file and run outside the debugger it works as expected, but will always fail when run in the debugger like below.
perl -de 1
Loading DB routines from perl5db.pl version 1.49_04
Editor support available.
Enter h or 'h h' for help, or 'man perldebug' for more help.
main::(-e:1): 1
DB<1> use DateTime
DB<2> $d = DateTime->now
DB<3> p $d
2016-12-21T00:42:44
DB<4> use DateTime::Format::CLDR
DB<5> $YMDHMSs_format = DateTime::Format::CLDR->new( pattern => 'yyyy-MM-ddTHH:mm:ss.SSSSS' );
DB<6> $d->set_formatter($YMDHMSs_format)
Can't call method "can" on unblessed reference at (eval 206)[/home/fms/local/perlbrew//perls/perl-5.24.0/lib/site_perl/5.24.0/Eval/Closure.pm:149] line 34, <DATA> line 1.
DB<7> $strp_format = DateTime::Format::Strptime->new( pattern => '%FT%R:%S.%N')
Can't locate object method "new" via package "DateTime::Format::Strptime" (perhaps you forgot to load "DateTime::Format::Strptime"?) at (eval 213)[/home/fms/local/perlbrew//perls/perl-5.24.0/lib/5.24.0/perl5db.pl:737] line 2, <DATA> line 1.
DB<8> use DateTime::Format::Strptime
DB<9> $strp_format = DateTime::Format::Strptime->new( pattern => '%FT%R:%S.%N')
DB<10> $d->set_formatter($strp_format)
Can't call method "can" on unblessed reference at (eval 206)[/home/fms/local/perlbrew//perls/perl-5.24.0/lib/site_perl/5.24.0/Eval/Closure.pm:149] line 34, <DATA> line 1.
DB<11> p $DateTime::VERSION
1.39
DB<12>
Tracing the set_formatter call gives this:
DB<5> t
Trace = on
DB<5> $d->set_formatter($YMDHMSs_format);
main::((eval 211)[/home/fms/local/perlbrew//perls/p524/lib/5.24.0/perl5db.pl:737]:2):
2: $d->set_formatter($YMDHMSs_format);;
DateTime::set_formatter(/home/fms/local/perlbrew//perls/p524/lib/site_perl/5.24.0/x86_64-linux/DateTime.pm:2055):
2055: my $self = shift;
DateTime::set_formatter(/home/fms/local/perlbrew//perls/p524/lib/site_perl/5.24.0/x86_64-linux/DateTime.pm:2056):
2056: my ($formatter) = $validator->(@_);
Eval::Closure::Sandbox_186::CODE(0x39e0cf8)((eval 206)[/home/fms/local/perlbrew//perls/p524/lib/site_perl/5.24.0/Eval/Closure.pm:149]:5):
5: sub { if ( @_ < 1 ) {
Eval::Closure::Sandbox_186::CODE(0x39e0cf8)((eval 206)[/home/fms/local/perlbrew//perls/p524/lib/site_perl/5.24.0/Eval/Closure.pm:149]:15):
15: if ( @_ > 1 ) {
Eval::Closure::Sandbox_186::CODE(0x39e0cf8)((eval 206)[/home/fms/local/perlbrew//perls/p524/lib/site_perl/5.24.0/Eval/Closure.pm:149]:34):
34: List::Util::all { $_[0]->can($_) } "format_datetime"
35: )
36: ) )
37: or Specio::Exception->throw( message => $_Specio_Constraint_Interface_message_generator59->($_[0]), type => $_Specio_Constraint_Interface_type59, value => $_[0] );;
List::Util::all((eval 206)[/home/fms/local/perlbrew//perls/p524/lib/site_perl/5.24.0/Eval/Closure.pm:149]:34):
34: List::Util::all { $_[0]->can($_) } "format_datetime"
35: )
36: ) )
37: or Specio::Exception->throw( message => $_Specio_Constraint_Interface_message_generator59->($_[0]), type => $_Specio_Constraint_Interface_type59, value => $_[0] );;
Can't call method "can" on unblessed reference at (eval 206)[/home/fms/local/perlbrew//perls/p524/lib/site_perl/5.24.0/Eval/Closure.pm:149] line 34, <DATA> line 1.
Hopefully this is enough information to debug and fix!
Add from_ymd() and from_datetime()
This is a parallel for epoch() & from_epoch(), very easy to implement, and will make life easier for users since they don't have to do regex acrobatics or involve a separate formatter module.
Upgrade to v1.47 causes Specio fatal exception
Upgrading from v1.46 to v1.47 causes my script to produce the following fatal exception:
Validation failed for type named Int declared in package Specio::Library::Builtins (/Library/Perl/5.18/Specio/Library/Builtins.pm) at line 163 in sub named (eval) with value 0.7
Trace begun at Specio::Exception->new line 57
Specio::Exception::throw('Specio::Exception', 'message', 'Validation failed for type named Int declared in package Specio::Library::Builtins (/Library/Perl/5.18/Specio/Library/Builtins.pm) at line 163 in sub named (eval) with value 0.7', 'type', 'Specio::Constraint::Simple=HASH(0x7f834c427c70)', 'value', 0.7) called at (eval 210) line 28
DateTime::Duration::_check_multiply_params(0.7, 1) called at /Library/Perl/5.18/darwin-thread-multi-2level/DateTime/Duration.pm line 286
DateTime::Duration::multiply('DateTime::Duration=HASH(0x7f834d828768)', 0.7, 1) called at /Library/Perl/5.18/darwin-thread-multi-2level/DateTime/Duration.pm line 340
DateTime::Duration::_multiply_overload('DateTime::Duration=HASH(0x7f834a2b6cc0)', 0.7, 1) called at cost_profile.pl line 244
main::process_timeline('ARRAY(0x7f8349b79020)', 0, undef, 70) called at cost_profile.pl line 206
main::check_resource_available('HASH(0x7f834f919068)', 'DateTime=HASH(0x7f834a5a05d8)', undef, undef, undef, 70) called at cost_profile.pl line 96
Issue is reproducible and is present in v1.48 also. Code works fine in v1.46 and earlier.
Seconds, milliseconds, microseconds or nanoseconds for DateTime::epoch()?
Please document the units returned by: DateTime::epoch() more prominently? Thanks!
DateTime crashed Devel::ptkdb
Migrated from rt.cpan.org #116924 (status was 'new')
Requestors:
From [email protected] on 2016-08-12 20:17:05:
DateTime doesn't seem to work nicely with Devel::ptkdb.
Firstly if I monitor a DateTime object it reports a stringified version of the object.
Secondly if a DateTime object is part of a bigger structure - adding the structure to the expression to be monitored simply crashes the GUI.
This is how I reproduced the error.
$ cat t.pl use DateTime;my $dt = DateTime->new(
year => 1964,
month => 10,
day => 16,
hour => 16,
minute => 12,
second => 47,
);
%arr = (k => $dt);
print %arr;
If I step up to line 14 then $dt shows 1964-10-16T16:12:47 and if I try to see %arr then the GUI crashes with the following error.
A DateTime object can only be compared to another DateTime object (DateTime=HASH(0x3066188), HASH(0x2a1c9c8)). at /cigdev64/borec/ExtData/2.0/opt/perl/lib/perl5/Devel/ptkdb.pm line 2658.
I can run the same script with perl -d and DataDumper correctly shows the complete hash structure of the object both in $dt and %arr without crashing.
I am using DateTime 1.34 Devel:,:ptkdb 1.1091 on perl 5.22.2
- Mithun
CONFIDENTIALITY AND SECURITY NOTICE
The contents of this message and any attachments may be confidential and proprietary. If you are not an intended recipient, please inform the sender of the transmission error and delete this message immediately without reading, distributing or copying the contents.
Constants for months/weekdays?
Migrated from rt.cpan.org #34912 (status was 'open')
Requestors:
Attachments:
From [email protected] (@polettix) on 2008-04-12 12:41:24:
Hi,
I think it would be useful to have some constants exported by the
module to refer to month names and weekdays, like JANUARY, JANUARY_0 and
so on. Otherwise, it's likely that the users will define such constants
by themselves (or worse hardcode them), leading to potential bugs.
I noticed this while reading http://use.perl.org/~Aristotle/journal/36022.
Cheers,
Flavio.
04epoch.t fails on Windows, perl <=5.10.1
Migrated from rt.cpan.org #83660 (status was 'open')
Requestors:
From [email protected] (@chorny) on 2013-02-27 11:04:39:
See http://matrix.cpantesters.org/?dist=DateTime+0.78
04epoch.t:
ok 29 - epoch should work back to at least 1904
Use of uninitialized value in subroutine entry at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 242.
Use of uninitialized value in subroutine entry at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 244.
Use of uninitialized value in subroutine entry at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 244.
Use of uninitialized value in subroutine entry at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 244.
Use of uninitialized value $second in numeric lt (<) at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 319.
Use of uninitialized value $second in numeric eq (==) at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 325.
Use of uninitialized value $p{"second"} in numeric gt (>) at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 269.
not ok 30 - year should be 1904
# Failed test 'year should be 1904'
# at t/04epoch.t line 126.
# got: '1899'
# expected: '1904'
not ok 31 - month should be 1904
# Failed test 'month should be 1904'
# at t/04epoch.t line 127.
# got: '12'
# expected: '1'
not ok 32 - day should be 1904
# Failed test 'day should be 1904'
# at t/04epoch.t line 128.
# got: '31'
# expected: '1'
ok 33 - epoch for 1 is -62135596800
ok 34 - epoch for 99 is -59042995200
ok 35 - epoch for 100 is -59011459200
ok 36 - epoch for 999 is -30641760000
ok 37 - can pass overloaded object to from_epoch
ok 38 - decimal epoch in overloaded object
Use of uninitialized value in subroutine entry at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 242.
Use of uninitialized value in subroutine entry at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 244.
Use of uninitialized value in subroutine entry at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 244.
Use of uninitialized value in subroutine entry at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 244.
Use of uninitialized value $second in numeric lt (<) at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 319.
Use of uninitialized value $second in numeric eq (==) at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 325.
Use of uninitialized value $p{"second"} in numeric gt (>) at
C:\strawberry\cpan\build\DateTime-0.78-ClXmIn\blib\lib/DateTime.pm line 269.
not ok 39 - negative epoch in overloaded object
# Failed test 'negative epoch in overloaded object'
# at t/04epoch.t line 173.
# got: '-2209075200'
# expected: '-12345'
ok 40 - 'asldkjlkjd' is not a valid epoch value
ok 41 - '1234 foo' is not a valid epoch value
ok 42 - 'adlkj 1234' is not a valid epoch value
1..42
# Looks like you failed 4 tests of 42.
--
Alexandr Ciornii, http://chorny.net
Rounding problems with nanosecond CLDR formatting
The following test script fails on many systems (mostly linux; I cannot reproduce the problem on freebsd):
#!/usr/bin/perl
use strict;
use warnings;
use DateTime;
use Test::More 'no_plan';
my $dt = DateTime->now;
$dt->set_nanosecond(10);
is '00000001000000', $dt->format_cldr('SSSSSSSSSSSSSS');
__END__
Output is:
not ok 1
# Failed test at /tmp/dt.pl line 10.
# got: '00000001000000'
# expected: '00000000999999'
1..1
# Looks like you failed 1 test of 1.
Probably this is caused by perl and/or POSIX::floor inaccuracies:
$ perl -MPOSIX=floor -E 'say floor(10/10**-5)'
999999
This is possibly the problem for the test failures seen in the DateTime::Format::CLDR module (@maros: FYI): https://rt.cpan.org/Public/Bug/Display.html?id=124691
Just an idea: avoiding the division and the negative exponent could help here. So if the exponent would be negative, then make it positive and multiply instead of divide:
$ perl -MPOSIX=floor -E 'say floor(10*10**5)'
1000000
It seems that this way the internal SV stays as an IV; otherwise it would be turned into a NV, possibly causing problems.
Proposed code change for _format_nanosecs (pseudo code, untested):
my $exponent = 9 - $precision;
my $formatted_ns = ($exponent < 0 ? $self->{rd_nanosecs} * 10**-$exponent : $self->{rd_nanosecs} / 10**$exponent);
... floor($formatted_ns) ...
Problems installing DateTimePackage
Migrated from rt.cpan.org #17390 (status was 'stalled')
Requestors:
Attachments:
From on 2006-01-31 10:53:08:
Hi,
I am unable to Make DateTime pm, seems like 97%+ tests are ok but at the
end i get a message
NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0xff'
and make stops saying "make test returned bad status, wont install
without force"
What should we do.
Please help
Devender
month+day duration disobeys arithmetic identity
Migrated from rt.cpan.org #87770 (status was 'new')
Requestors:
From [email protected] on 2013-08-11 16:03:45:
With DateTime-1.03:
$dt0 = DateTime->new(year => 2013, month => 6, day => 30);
$dt1 = DateTime->new(year => 2013, month => 8, day => 31);
$dur = $dt1 - $dt0;
# $dur is 2 months + 1 day
print $dt0 + $dur;
# => 2013-09-01$dur is representing the interval between these dates in a sensible way.
Applying the interval to $dt0 has to be done by adding the 2 months
first and then the 1 day, but ->add_duration actually does it the other
way round. It adds 1 day to 2013-06-30 to get 2013-07-01, and then adds
on 2 months to get 2013-09-01, not matching the original $dt1.
DateTime's additive arithmetic fundamentally cannot obey the usual
arithmetic identities. It'll inevitably get into trouble with things
like ($dt + $dur0 + $dur1 - $dur0 - $dur1). But the above should be
an easy case, as it's applying a duration to represent exactly the same
calendar interval from which it was generated. The problem is that the
addition operation is not the converse of the subtraction, and that's
occurring because it's internally turning the easy case into the kind
of case that's inherent trouble.
-zefram
day_of_year in constructor parameters
would be nice to have a constructor like
- new DateTime(year=>$yr, doy=>$doy, ...).
We use year-day_of_year quite a lot when dealing with satellite data sets.
Suggest adding stringify()
Overloading to obtain the string version of a DateTime works well in most cases, but not all. Full issue described and discussed here:
https://stackoverflow.com/questions/45469748/true-stringify-of-datetime
Can't locate DateTime/TimeZone/OlsonDB/Change.pm
./cpan install DateTime
Loading internal null logger. Install Log::Log4perl for logging messages
CPAN: Storable loaded ok (v2.56)
Reading '/root/.cpan/Metadata'
Database was generated on Thu, 23 Nov 2017 05:17:02 GMT
Running install for module 'DateTime'
CPAN: Digest::SHA loaded ok (v5.95)
CPAN: Compress::Zlib loaded ok (v2.069)
Checksum for /root/.cpan/sources/authors/id/D/DR/DROLSKY/DateTime-1.44.tar.gz ok
CPAN: File::Temp loaded ok (v0.2304)
'YAML' not installed, will not store persistent state
CPAN: CPAN::Meta::Requirements loaded ok (v2.140)
CPAN: Parse::CPAN::Meta loaded ok (v1.4417)
CPAN: CPAN::Meta loaded ok (v2.150005)
CPAN: Module::CoreList loaded ok (v5.20160506)
Configuring D/DR/DROLSKY/DateTime-1.44.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for DateTime
Writing MYMETA.yml and MYMETA.json
DROLSKY/DateTime-1.44.tar.gz
/data/scripts/nices/perl/bin/perl Makefile.PL -- OK
Running make for D/DR/DROLSKY/DateTime-1.44.tar.gz
cp lib/DateTime/PPExtra.pm blib/lib/DateTime/PPExtra.pm
cp lib/DateTime.pm blib/lib/DateTime.pm
cp lib/DateTime/LeapSecond.pm blib/lib/DateTime/LeapSecond.pm
cp lib/DateTime/Duration.pm blib/lib/DateTime/Duration.pm
cp lib/DateTime/Helpers.pm blib/lib/DateTime/Helpers.pm
cp lib/DateTime/Conflicts.pm blib/lib/DateTime/Conflicts.pm
cp lib/DateTime/Infinite.pm blib/lib/DateTime/Infinite.pm
cp lib/DateTime/PP.pm blib/lib/DateTime/PP.pm
cp lib/DateTime/Types.pm blib/lib/DateTime/Types.pm
Running Mkbootstrap for DateTime ()
chmod 644 "DateTime.bs"
"/data/scripts/nices/perl/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- DateTime.bs blib/arch/auto/DateTime/DateTime.bs 644
"/data/scripts/nices/perl/bin/perl" "/data/scripts/nices/perl/lib/5.24.0/ExtUtils/xsubpp" -typemap '/data/scripts/nices/perl/lib/5.24.0/ExtUtils/typemap' DateTime.xs > DateTime.xsc
mv DateTime.xsc DateTime.c
cc -c -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -DVERSION="1.44" -DXS_VERSION="1.44" -fPIC "-I/data/scripts/nices/perl/lib/5.24.0/x86_64-linux/CORE" DateTime.c
rm -f blib/arch/auto/DateTime/DateTime.so
cc -shared -O2 -L/usr/local/lib -fstack-protector DateTime.o -o blib/arch/auto/DateTime/DateTime.so
\
chmod 755 blib/arch/auto/DateTime/DateTime.so
DROLSKY/DateTime-1.44.tar.gz
/usr/bin/make -- OK
Running make test
"/data/scripts/nices/perl/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- DateTime.bs blib/arch/auto/DateTime/DateTime.bs 644
PERL_DL_NONLAZY=1 "/data/scripts/nices/perl/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/.t
t/00-report-prereqs.t .... #
Versions for all modules listed in MYMETA.json (including optional ones):
=== Configure Requires ===
Module Want Have
-------------------- ---- ----
Dist::CheckConflicts 0.02 0.11
ExtUtils::MakeMaker any 7.24
=== Configure Suggests ===
Module Want Have
-------- ------- -------
JSON::PP 2.27300 2.27300
=== Build Requires ===
Module Want Have
------------------- ---- ----
ExtUtils::MakeMaker any 7.24
=== Test Requires ===
Module Want Have
------------------------ ----- --------
CPAN::Meta::Check 0.011 0.014
CPAN::Meta::Requirements any 2.140
ExtUtils::MakeMaker any 7.24
File::Spec any 3.63
Storable any 2.56
Test::Fatal any 0.014
Test::More 0.96 1.302062
Test::Warnings 0.005 0.026
utf8 any 1.19
=== Test Recommends ===
Module Want Have
---------- -------- --------
CPAN::Meta 2.120900 2.150005
=== Runtime Requires ===
Module Want Have
-------------------------- ---- -----
Carp any 1.40
DateTime::Locale 1.06 1.10
DateTime::TimeZone 2.02 2.07
Dist::CheckConflicts 0.02 0.11
POSIX any 1.65
Params::ValidationCompiler 0.13 0.16
Scalar::Util any 1.46
Specio 0.18 0.30
Specio::Declare any 0.30
Specio::Exporter any 0.30
Specio::Library::Builtins any 0.30
Specio::Library::Numeric any 0.30
Specio::Library::String any 0.30
Try::Tiny any 0.27
XSLoader any 0.24
base any 2.23
integer any 1.01
namespace::autoclean 0.19 0.28
overload any 1.26
parent any 0.234
strict any 1.11
warnings any 1.36
warnings::register any 1.04
t/00-report-prereqs.t .... ok
t/00load.t ............... 1/?
Failed test 'use DateTime;'
at t/00load.t line 6.
Tried to use 'DateTime'.
Error: Can't locate DateTime/TimeZone/OlsonDB/Change.pm in @inc (you may need to install the DateTime::TimeZone::OlsonDB::Change module) (@inc contains: /root/.cpan/build/DateTime-1.44-uYlKPY/blib/lib /root/.cpan/build/DateTime-1.44-uYlKPY/blib/arch /data/scripts/nices/perl/lib/site_perl/5.24.0/x86_64-linux /data/scripts/nices/perl/lib/site_perl/5.24.0 /data/scripts/nices/perl/lib/5.24.0/x86_64-linux /data/scripts/nices/perl/lib/5.24.0 .) at /data/scripts/nices/perl/lib/site_perl/5.24.0/DateTime/TimeZone.pm line 15, line 1.
BEGIN failed--compilation aborted at /data/scripts/nices/perl/lib/site_perl/5.24.0/DateTime/TimeZone.pm line 15, line 1.
Compilation failed in require at /root/.cpan/build/DateTime-1.44-uYlKPY/blib/lib/DateTime.pm line 17, line 1.
BEGIN failed--compilation aborted at /root/.cpan/build/DateTime-1.44-uYlKPY/blib/lib/DateTime.pm line 17, line 1.
Compilation failed in require at t/00load.t line 6, line 1.
BEGIN failed--compilation aborted at t/00load.t line 6, line 1.
Looks like you failed 1 test of 1.
t/00load.t ............... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
t/01sanity.t ............. Can't locate DateTime/TimeZone/OlsonDB/Change.pm in @inc (you may need to install the DateTime::TimeZone::OlsonDB::Change module) (@inc contains: /root/.cpan/build/DateTime-1.44-uYlKPY/blib/lib /root/.cpan/build/DateTime-1.44-uYlKPY/blib/arch /data/scripts/nices/perl/lib/site_perl/5.24.0/x86_64-linux /data/scripts/nices/perl/lib/site_perl/5.24.0 /data/scripts/nices/perl/lib/5.24.0/x86_64-linux /data/scripts/nices/perl/lib/5.24.0 .) at /data/scripts/nices/perl/lib/site_perl/5.24.0/DateTime/TimeZone.pm line 15, line 1.
BEGIN failed--compilation aborted at /data/scripts/nices/perl/lib/site_perl/5.24.0/DateTime/TimeZone.pm line 15, line 1.
Compilation failed in require at /root/.cpan/build/DateTime-1.44-uYlKPY/blib/lib/DateTime.pm line 17, line 1.
BEGIN failed--compilation aborted at /root/.cpan/build/DateTime-1.44-uYlKPY/blib/lib/DateTime.pm line 17, line 1.
Compilation failed in require at t/01sanity.t line 6, line 1.
BEGIN failed--compilation aborted at t/01sanity.t line 6, line 1.
t/01sanity.t ............. Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
t/02last-day.t ........... Can't locate DateTime/TimeZone/OlsonDB/Change.pm in @inc (you may need to install the DateTime::TimeZone::OlsonDB::Change module) (@inc contains: /root/.cpan/build/DateTime-1.44-uYlKPY/blib/lib /root/.cpan/build/DateTime-1.44-uYlKPY/blib/arch /data/scripts/nices/perl/lib/site_perl/5.24.0/x86_64-linux /data/scripts/nices/perl/lib/site_perl/5.24.0 /data/scripts/nices/perl/lib/5.24.0/x86_64-linux /data/scripts/nices/perl/lib/5.24.0 .) at /data/scripts/nices/perl/lib/site_perl/5.24.0/DateTime/TimeZone.pm line 15, line 1.
BEGIN failed--compilation aborted at /data/scripts/nices/perl/lib/site_perl/5.24.0/DateTime/TimeZone.pm line 15, line 1.
Compilation failed in require at /root/.cpan/build/DateTime-1.44-uYlKPY/blib/lib/DateTime.pm line 17, line 1.
BEGIN failed--compilation aborted at /root/.cpan/build/DateTime-1.44-uYlKPY/blib/lib/DateTime.pm line 17, line 1.
Compilation failed in require at t/02last-day.t line 7, line 1.
BEGIN failed--compilation aborted at t/02last-day.t line 7, line 1.
DateTime.pm v075 do not install into x86_64-linux folder
Migrated from rt.cpan.org #77920 (status was 'stalled')
Requestors:
From [email protected] on 2012-06-20 11:34:12:
Hi all
I tried to upgrade DateTime from v0.50 to V.75
DateTime installs here:
:
Prepending /root/.cpan/build/DateTime-0.75-SOd13E/blib/arch /root/.cpan/build/DateTime-0.75-SOd13E/blib/lib to PERL5LIB for 'install'
Building DateTime
Installing /opt/perl/lib/site_perl/5.8.9/DateTime.pm
Installing /opt/perl/lib/site_perl/5.8.9/DateTimePP.pm
Installing /opt/perl/lib/site_perl/5.8.9/DateTimePPExtra.pm
Installing /opt/perl/lib/site_perl/5.8.9/DateTime/Duration.pm
Installing /opt/perl/lib/site_perl/5.8.9/DateTime/Helpers.pm
Installing /opt/perl/lib/site_perl/5.8.9/DateTime/Infinite.pm
Installing /opt/perl/lib/site_perl/5.8.9/DateTime/LeapSecond.pm
Installing /opt/perl/man/man3/DateTime::Infinite.3
Installing /opt/perl/man/man3/DateTime.3
Installing /opt/perl/man/man3/DateTime::Duration.3
Installing /opt/perl/man/man3/DateTime::LeapSecond.3
DROLSKY/DateTime-0.75.tar.gz
./Build install -- OK
But when I run:
/opt/perl/bin/perl -e 'use DateTime; print "$DateTime::VERSION\n";'
0.50
cat /opt/perl/lib/site_perl/5.8.9/DateTime.pm | grep DateTime::VERSION
$DateTime::VERSION = '0.75';
$serialized .= "version:$DateTime::VERSION";
find /opt/perl/ -name 'DateTime.pm'
/opt/perl/lib/site_perl/5.8.9/x86_64-linux/DateTime.pm
/opt/perl/lib/site_perl/5.8.9/DateTime.pm
cat /opt/perl/lib/site_perl/5.8.9/x86_64-linux/DateTime.pm | grep VERSION
our $VERSION;
$VERSION = '0.50';
XSLoader::load( 'DateTime', $DateTime::VERSION );
$serialized .= "version:$VERSION";
So it seems to me it is forgetting to install under /opt/perl/lib/site_perl/5.8.9/x86_64-linux/
Doing this as root seem to fix it:
cp -rv /opt/perl/lib/site_perl/5.8.9/DateTime* /opt/perl/lib/site_perl/5.8.9/x86_64-linux/
Then most of our code seem to work fine.
A bit ugly?
Is it my custom build perl 5.8.9 under /opt/perl that confuses it?
I'm building on an opensuse 11.4 X86_64 with system perl 5.12.3
Thanks
Morten Bjoernsvik
Senior Developer Secana
Evry Card Services AS
FR: Implement $dt->days, $dt->last_day
I see this function useful when we want to get count of days in current month or DateTime object for last day in current month.
Please implement if you see them useful too
*FR: Feature request
Performance regressions due to Specio
Hey, first and foremost, thanks for DateTime. I have worked on custom date/time libraries in the past and I really appreciate not going through that experience again, not my cup of tea, way too complicated and too many edge cases/pitfalls.
Saying that, we are updating our infrastructure and ran into performance regressions. We noticed our application was running a bit slower on the updated platform.
After debugging with Devel::NYTProf [1] and inspecting the stack call flamegraph [2][3], we noticed that loading DateTime took 77.79% (from consuming 1.89% of our application to 8.47%) more time than previously. After investigating it was clear that this regression was introduced with commit 3308e9e.
[1] https://metacpan.org/pod/Devel::NYTProf
[2] http://www.brendangregg.com/flamegraphs.html
[3] https://github.com/brendangregg/FlameGraph
Screencaps before the regression:
Screencaps after the regression:
DateTime failed tests; could not locate Class::ISA
Migrated from rt.cpan.org #75223 (status was 'stalled')
Requestors:
Attachments:
From [email protected] on 2012-02-22 19:45:44:
Today I attempted to install with 'cpan' a distro for which DateTime was
an explicit prerequisite. That installation failed, citing DateTime as
one of the missing prereqs. I know for a fact that DateTime was
previously installed on this machine (probably via a Debian package), so
I was surprised at this. I went to install DateTime with 'cpan'. It
appeared to build okay, but when the tests began I got output starting
like the attached.
I was surprised at that, because I know that I had Class::ISA in the
past. Nonetheless, I moved forward by using 'cpan' to install
Class::ISA. After that, I was able to (re-)install DateTime.
So, why did Class::ISA get picked up as a dependency and cause tests to
fail?
Is the fact that Class::ISA is no longer in the Perl 5 core distro
relevant here?
$ corelist Class::ISA
Class::ISA was first released with perl v5.7.3 and removed from v5.13.1
Thank you very much.
Jim Keenan
POD link broken on CPAN
In sentence:
If you can always use the floating or UTC time zones, you can skip ahead to Leap Seconds and Date Math.
Which points incorrectly to http://search.cpan.org/perldoc?Leap%20Seconds%20and%20Date%20Math
silly seconds value at leap second
Migrated from rt.cpan.org #71272 (status was 'open')
Requestors:
From [email protected] on 2011-09-27 12:05:51:
$ perl -MDateTime -lwe '$dt=DateTime->new(year=>2008,month=>12,day=>31,hour=>23,minute=>59,second=>60, time_zone=>"UTC"); $dt->set_time_zone("+00:00:59"); print $dt'
2009-01-01T23:59:119
Only happens for a time located within a leap second, when combined with
a timezone offset that is not an integral number of minutes. That's an
inherently problematic combination, but giving a reading of 119 seconds
into the minute is not an acceptable response. You could fudge it to
give the same (sane) response as the preceding or following second,
00:00:58 or 00:00:59, or you could throw an exception.
-zefram
More user-friendly error message than "parameter not listed in the validation options"
Migrated from rt.cpan.org #46947 (status was 'open')
Requestors:
From [email protected] on 2009-06-15 10:08:49:
Running the code my $date2 = $date1->subtract(day => 1), will produce
the error below:
The following parameter was passed in the call to DateTime::Duration::new but was not listed in the validation options: day
Huh?
It actually took me a while to realize the typo ("days" instead of
"day") because the error message hinted at 'DateTime::Duration::new"
being called, which was not readily apparent. Plus, what are the
"validation options"? Couldn't find anything about that on (anno)CPAN.
Would be nicer to get an error message like:
'day' is not a valid parameter for ->subtract
Unable to upgrade DateTime via 'cpanm'
Migrated from rt.cpan.org #103537 (status was 'new')
Requestors:
Attachments:
From [email protected] on 2015-04-14 13:35:45:
I am having difficulty upgrading DateTime via 'cpanm' on the machine described in the perl_V attachment.
Let me say at the outset that the version of DateTime currently installed is in a directory tree governed by local::lib, i.e., it's in a location dictated by job requirements rather than by my own use of 'cpanm', 'cpan', etc.
The currently installed versions of relevant packages, as observed via 'perldoc -m ', are:
DateTime: 0.72
DateTime::Locale: 0.45
DateTime::TimeZone: 1.42
The full output of 'cpanm', the build logs, etc., are attached. Here I quote relevant extracts.
$ cpanm DateTime
--> Working on DateTime
Fetching http://www.cpan.org/authors/id/D/DR/DROLSKY/DateTime-1.18.tar.gz ... OK
Configuring DateTime-1.18 ... OK
==> Found dependencies: DateTime::TimeZone
--> Working on DateTime::TimeZone
Fetching http://www.cpan.org/authors/id/D/DR/DROLSKY/DateTime-TimeZone-1.86.tar.gz ... OK
Configuring DateTime-TimeZone-1.86 ... OK
Building and testing DateTime-TimeZone-1.86 ... FAIL
! Installing DateTime::TimeZone failed. See /Users/jkeenan/.cpanm/work/1429017224.40597/build.log for details. Retry with --force to force install it.
! Installing the dependencies failed: Installed version (1.42) of DateTime::TimeZone is not in range '1.74'
! Bailing out the installation for DateTime-1.18.
Switching into the .cpanm/work directory and examining the build log, I see the following:
cpanm (App::cpanminus) 1.7014 on perl 5.020001 built for darwin-2level
Work directory is /Users/jkeenan/.cpanm/work/1429017224.40597
[snip]
--> Working on DateTime
Fetching http://www.cpan.org/authors/id/D/DR/DROLSKY/DateTime-1.18.tar.gz
-> OK
[snip]
Checking prerequisites...
requires:
! DateTime::TimeZone (1.42) is installed, but we need version >= 1.74
ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the versions
of the modules indicated above before proceeding with this installation
[snip]
==> Found dependencies: DateTime::TimeZone
Searching DateTime::TimeZone on cpanmetadb ...
--> Working on DateTime::TimeZone
Fetching http://www.cpan.org/authors/id/D/DR/DROLSKY/DateTime-TimeZone-1.86.tar.gz
-> OK
Unpacking DateTime-TimeZone-1.86.tar.gz
Entering DateTime-TimeZone-1.86
[snip]
t/00-report-prereqs.t ....... ok
Use of uninitialized value in subroutine entry at /Users/jkeenan/adama/extlib/lib/perl5/DateTime/Locale.pm line 41.
t/02basic.t .................
No subtests run
Use of uninitialized value in subroutine entry at /Users/jkeenan/adama/extlib/lib/perl5/DateTime/Locale.pm line 41.
[snip]
Files=26, Tests=65, 7 wallclock secs ( 0.08 usr 0.06 sys + 1.47 cusr 0.23 csys = 1.84 CPU)
Result: FAIL
Failed 15/26 test programs. 0/65 subtests failed.
make: *** [test_dynamic] Error 255
-> FAIL Installing DateTime::TimeZone failed. See /Users/jkeenan/.cpanm/work/1429017224.40597/build.log for details. Retry with --force to force install it.
-> FAIL Installing the dependencies failed: Installed version (1.42) of DateTime::TimeZone is not in range '1.74'
-> FAIL Bailing out the installation for DateTime-1.18.
I next tried to use 'cpanm' to install DateTime::TimeZone.
$ cpanm DateTime::TimeZone
--> Working on DateTime::TimeZone
Fetching http://www.cpan.org/authors/id/D/DR/DROLSKY/DateTime-TimeZone-1.86.tar.gz ... OK
Configuring DateTime-TimeZone-1.86 ... OK
Building and testing DateTime-TimeZone-1.86 ... FAIL
! Installing DateTime::TimeZone failed. See /Users/jkeenan/.cpanm/work/1429018096.40949/build.log for details. Retry with --force to force install it.
Examining this most recent build log, I see:
cpanm (App::cpanminus) 1.7014 on perl 5.020001 built for darwin-2level
[snip]
--> Working on DateTime::TimeZone
Fetching http://www.cpan.org/authors/id/D/DR/DROLSKY/DateTime-TimeZone-1.86.tar.gz
-> OK
t/00-report-prereqs.t ....... ok
Use of uninitialized value in subroutine entry at /Users/jkeenan/adama/extlib/lib/perl5/DateTime/Locale.pm line 41.
t/02basic.t .................
No subtests run
Use of uninitialized value in subroutine entry at /Users/jkeenan/adama/extlib/lib/perl5/DateTime/Locale.pm line 41.
[snip]
Files=26, Tests=65, 4 wallclock secs ( 0.08 usr 0.05 sys + 1.39 cusr 0.20 csys = 1.72 CPU)
Result: FAIL
Failed 15/26 test programs. 0/65 subtests failed.
make: *** [test_dynamic] Error 255
-> FAIL Installing DateTime::TimeZone failed. See /Users/jkeenan/.cpanm/work/1429018096.40949/build.log for details. Retry with --force to force install it.
Should I try to install DateTime::Locale, I am told that it is already up-to-date.
$ cpanm DateTime::Locale
DateTime::Locale is up to date. (0.45)
String comparison of two DateTime objects too accurate?
Migrated from rt.cpan.org #57743 (status was 'open')
Requestors:
From [email protected] (@schwern) on 2010-05-22 00:31:33:
DateTime currently uses (after a lot of scaffolding) utc_rd_values() to
perform a string comparison between two DateTime objects. This takes
into account nanoseconds. Since the default string form does not show
nanoseconds it leads to the strange case where two apparently equal
strings are not equal.
For example:
use DateTime;
my $foo = DateTime->new(year => 2010, nanosecond => 123);
my $bar = DateTime->new(year => 2010, nanosecond => 456);
print $foo eq $bar ? "Equal" : "Not equal";
print $foo;
print $bar;'
END
Not equal
2010-01-01T00:00:00
2010-01-01T00:00:00
I'm not sure what's to be done with this, but it is difficult to debug.
One choice is to leave "eq" as a string comparison operator and just
compare DateTime objects as strings rather than as dates. This removes
the surprise, but it also removes a possibly valuable increased accuracy
and its probably backwards compatible.
Another is to compare using lower accuracy, one more in line with what's
displayed, such as utc_rd_as_seconds. This will bring the results in
line with the level of accuracy shown in the default string
representation while retaining cross time zone equality. OTOH people
may change the string format to one that includes nanoseconds, and its
probably backwards incompatible.
Another is to throw a warning when a string comparison fails because of
a nanosecond difference. OTOH this may get noisy.
build-time warning introduced during perl-5.27-* development cycle
Today I began working with a git checkout of DateTime in a FreeBSD-11 VM I intend to use for testing "blead-breaks-CPAN" activity during the upcoming development cycle. I had occasion to build DateTime with both the "system" perl (5.26.2) and with perl-5.27.11. I noted that between those two points a build-time warning began to appear, probably due to some change in perl blead over that time. I did not notice any difference in make test, but you may wish to investigate and eliminate that warning.
perl-5.26.2
$ perl Makefile.PL
***
Your toolchain doesn't support configure_requires, so Dist::CheckConflicts
hasn't been installed yet. You should check for conflicting modules
manually by examining the list of conflicts in DateTime::Conflicts once the installation
finishes.
***
Generating a Unix-style Makefile
Writing Makefile for DateTime
Writing MYMETA.yml and MYMETA.json
[pmsg-vm: DateTime.pm] $ make
cp lib/DateTime/Helpers.pm blib/lib/DateTime/Helpers.pm
[snip]
cp lib/DateTime/PPExtra.pm blib/lib/DateTime/PPExtra.pm
Running Mkbootstrap for DateTime ()
chmod 644 "DateTime.bs"
"/usr/local/bin/perl5.26.2" -MExtUtils::Command::MM -e 'cp_nonempty' -- DateTime.bs blib/arch/auto/DateTime/DateTime.bs 644
"/usr/local/bin/perl5.26.2" "/usr/local/lib/perl5/5.26/ExtUtils/xsubpp" -typemap '/usr/local/lib/perl5/5.26/ExtUtils/typemap' DateTime.xs > DateTime.xsc
mv DateTime.xsc DateTime.c
cc -c -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_FORTIFY_SOURCE=2 -O2 -pipe -fstack-protector -fno-strict-aliasing -DVERSION=\"1.49\" -DXS_VERSION=\"1.49\" -DPIC -fPIC "-I/usr/local/lib/perl5/5.26/mach/CORE" DateTime.c
rm -f blib/arch/auto/DateTime/DateTime.so
cc -shared -L/usr/local/lib/perl5/5.26/mach/CORE -lperl -L/usr/local/lib -fstack-protector-strong DateTime.o -o blib/arch/auto/DateTime/DateTime.so
chmod 755 blib/arch/auto/DateTime/DateTime.so
Manifying 5 pod documents
perl-5.27.11
$ this_perl Makefile.PL
***
Your toolchain doesn't support configure_requires, so Dist::CheckConflicts
hasn't been installed yet. You should check for conflicting modules
manually by examining the list of conflicts in DateTime::Conflicts once the installation
finishes.
***
Generating a Unix-style Makefile
Writing Makefile for DateTime
Writing MYMETA.yml and MYMETA.json
[pmsg-vm: DateTime.pm] $ make
cp lib/DateTime.pm blib/lib/DateTime.pm
[snip]
cp lib/DateTime/Infinite.pm blib/lib/DateTime/Infinite.pm
Running Mkbootstrap for DateTime ()
chmod 644 "DateTime.bs"
"/usr/home/jkeenan/var/tad/testing/perl-5.27.11/bin/perl5.27.11" -MExtUtils::Command::MM -e 'cp_nonempty' -- DateTime.bs blib/arch/auto/DateTime/DateTime.bs 644
"/usr/home/jkeenan/var/tad/testing/perl-5.27.11/bin/perl5.27.11" "/usr/home/jkeenan/var/tad/testing/perl-5.27.11/lib/5.27.11/ExtUtils/xsubpp" -typemap '/usr/home/jkeenan/var/tad/testing/perl-5.27.11/lib/5.27.11/ExtUtils/typemap' DateTime.xs > DateTime.xsc
mv DateTime.xsc DateTime.c
cc -c -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_FORTIFY_SOURCE=2 -O2 -DVERSION=\"1.49\" -DXS_VERSION=\"1.49\" -DPIC -fPIC "-I/usr/home/jkeenan/var/tad/testing/perl-5.27.11/lib/5.27.11/amd64-freebsd/CORE" DateTime.c
In file included from DateTime.xs:5:
./ppport.h:4594:11: warning: 'WIDEST_UTYPE' macro redefined [-Wmacro-redefined]
# define WIDEST_UTYPE U64TYPE
^
/usr/home/jkeenan/var/tad/testing/perl-5.27.11/lib/5.27.11/amd64-freebsd/CORE/handy.h:1064:12: note:
previous definition is here
# define WIDEST_UTYPE U64
^
1 warning generated.
rm -f blib/arch/auto/DateTime/DateTime.so
cc -shared -L/usr/local/lib -fstack-protector-strong DateTime.o -o blib/arch/auto/DateTime/DateTime.so
chmod 755 blib/arch/auto/DateTime/DateTime.so
Thank you very much.
Jim Keenan
Unexpected delta math surrounding DST
In DateTime 1.50, when using delta_ms and delta_minutes to get the number of minutes between certain sets of times last Friday and this past Monday (on either side of the DST changeover), I ended up with a result that was 1440 minutes (24 hours) larger than expected.
See the attached test cases for two examples that are working:
- Fri 12:30 to Mon 12:30 = 4320 minutes (72 hours)
- Fri 12:30 to Mon 12:40 = 4330 minutes (72 hours plus 10 minutes)
... and one that isn't:
- Fri 12:30 to Mon 12:20 should return 4310 minutes (72 hours minus 10 minutes), but actually returns 5750 minutes (96 hours minus 10 minutes).
I'm not suggesting that it should be 73 hours instead of 72 -- I see that DateTime does some relative math rather than being pedantic, and I'm fine with that, especially when DST is involved. "Off by 24 hours" seems like a bug, though.
Test suite failures when Sub::Util isn't present
$ make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
#
# Versions for all modules listed in MYMETA.json (including optional ones):
#
# === Configure Requires ===
#
# Module Want Have
# -------------------- ---- ----
# Dist::CheckConflicts 0.02 0.11
# ExtUtils::MakeMaker any 6.68
#
# === Configure Suggests ===
#
# Module Want Have
# -------- ------- -------
# JSON::PP 2.27300 2.97001
#
# === Build Requires ===
#
# Module Want Have
# ------------------- ---- ----
# ExtUtils::MakeMaker any 6.68
#
# === Test Requires ===
#
# Module Want Have
# ------------------------ ----- --------
# CPAN::Meta::Check 0.011 0.014
# CPAN::Meta::Requirements any 2.140
# ExtUtils::MakeMaker any 6.68
# File::Spec any 3.40
# Storable any 2.45
# Test::Fatal any 0.014
# Test::More 0.96 1.302133
# Test::Warnings 0.005 0.026
# utf8 any 1.09
#
# === Test Recommends ===
#
# Module Want Have
# ---------- -------- --------
# CPAN::Meta 2.120900 2.150010
#
# === Runtime Requires ===
#
# Module Want Have
# -------------------------- ---- -----
# Carp any 1.26
# DateTime::Locale 1.06 1.17
# DateTime::TimeZone 2.02 2.17
# Dist::CheckConflicts 0.02 0.11
# POSIX any 1.30
# Params::ValidationCompiler 0.26 0.27
# Scalar::Util any 1.27
# Specio 0.18 0.42
# Specio::Declare any 0.42
# Specio::Exporter any 0.42
# Specio::Library::Builtins any 0.42
# Specio::Library::Numeric any 0.42
# Specio::Library::String any 0.42
# Try::Tiny any 0.30
# XSLoader any 0.16
# base any 2.18
# integer any 1.00
# namespace::autoclean 0.19 0.28
# overload any 1.18
# parent any 0.236
# strict any 1.07
# warnings any 1.13
# warnings::register any 1.02
#
t/00-report-prereqs.t .... ok
# Failed test 'use DateTime;'
# at t/00load.t line 6.
# Tried to use 'DateTime'.
# Error: Cannot name a generated validation subroutine. Please install Sub::Util. at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime/Duration.pm line 276.
# Compilation failed in require at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime.pm line 14.
# BEGIN failed--compilation aborted at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime.pm line 14.
# Compilation failed in require at t/00load.t line 6.
# BEGIN failed--compilation aborted at t/00load.t line 6.
# Looks like you failed 1 test of 1.
t/00load.t ...............
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
Cannot name a generated validation subroutine. Please install Sub::Util. at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime/Duration.pm line 276.
Compilation failed in require at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime.pm line 14.
BEGIN failed--compilation aborted at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime.pm line 14.
Compilation failed in require at t/01sanity.t line 6.
BEGIN failed--compilation aborted at t/01sanity.t line 6.
t/01sanity.t .............
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
Cannot name a generated validation subroutine. Please install Sub::Util. at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime/Duration.pm line 276.
Compilation failed in require at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime.pm line 14.
BEGIN failed--compilation aborted at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime.pm line 14.
Compilation failed in require at t/02last-day.t line 7.
BEGIN failed--compilation aborted at t/02last-day.t line 7.
t/02last-day.t ...........
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
Cannot name a generated validation subroutine. Please install Sub::Util. at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime/Duration.pm line 276.
Compilation failed in require at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime.pm line 14.
BEGIN failed--compilation aborted at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime.pm line 14.
Compilation failed in require at t/03components.t line 6.
BEGIN failed--compilation aborted at t/03components.t line 6.
t/03components.t .........
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
Cannot name a generated validation subroutine. Please install Sub::Util. at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime/Duration.pm line 276.
Compilation failed in require at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime.pm line 14.
BEGIN failed--compilation aborted at /builddir/build/BUILD/DateTime-1.47/blib/lib/DateTime.pm line 14.
Compilation failed in require at t/04epoch.t line 7.
BEGIN failed--compilation aborted at t/04epoch.t line 7.
t/04epoch.t ..............
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
...
t/48rt-115983.t ..........
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
Warning: DateTime::Format::Strptime did not compile at /usr/share/perl5/vendor_perl/Dist/CheckConflicts.pm line 184.
# Conflicts detected for DateTime:
# DateTime::Format::Strptime is version unknown, but must be greater than version 1.1000
t/zzz-check-breaks.t ..... ok
Test Summary Report
-------------------
t/00load.t (Wstat: 256 Tests: 1 Failed: 1)
Failed test: 1
Non-zero exit status: 1
...
t/48rt-115983.t (Wstat: 512 Tests: 0 Failed: 0)
Non-zero exit status: 2
Parse errors: No plan found in TAP output
Files=50, Tests=6, 5 wallclock secs ( 0.06 usr 0.03 sys + 4.05 cusr 0.45 csys = 4.59 CPU)
Result: FAIL
Failed 48/50 test programs. 3/6 subtests failed.
make: *** [test_dynamic] Error 255
add ability to fetch week_number and week_year for locales with specified first_day_of_week
Migrated from rt.cpan.org #83558 (status was 'patched')
Requestors:
From [email protected] on 2013-02-22 23:30:13:
Our weeks start on a Saturday (don't ask), I've created a locale class overriding first_day_of_week, like so:
sub first_day_of_week {6}I assumed this would then change the numbers generated by week/week_number/week_year, but that didn't seem to be the case.
The code below can just be added to DateTime somewhere to provide local_ equivalents of the week number methods, returning the local numbers. As commented, it might be able to be optimised a little bit, I'm not quite clear on exactly what some of the maths is doing, to substitute the local first day of week. I guess it may also be worth adding some additional options in some of the formatting stuff, although you don't seem to have many letters left.
sub local_week {
my $self = shift;
unless ( defined $self->{local_c}{local_week_year} ) {
my $jan_one_dow_m1
# This algorithm was taken from Date::Calc's DateCalc.c file
#= ( ( $self->_ymd2rd( $self->year, 1, 1 ) + 6 ) % 7 );
#Work out how the above needs translating to use the local
day, reinterpreted based on Date::Calc::PP's DateCalc_Week_Number
= ( ( DateTime->new(year => $self->year, month => 1, day =>
1, locale => $self->locale())->local_day_of_week() ) - 1);
$self->{local_c}{local_week_number}
= int( ( ( $self->{local_c}{day_of_year} - 1 ) +
$jan_one_dow_m1 ) / 7 );
$self->{local_c}{local_week_number}++ if $jan_one_dow_m1 < 4;
if ( $self->{local_c}{local_week_number} == 0 ) {
$self->{local_c}{local_week_year} = $self->year - 1;
$self->{local_c}{local_week_number}
= $self->_local_weeks_in_year(
$self->{local_c}{local_week_year} );
}
elsif ($self->{local_c}{local_week_number} == 53
&& $self->_local_weeks_in_year( $self->year ) == 52 ) {
$self->{local_c}{local_week_number} = 1;
$self->{local_c}{local_week_year} = $self->year + 1;
}
else {
$self->{local_c}{local_week_year} = $self->year;
}
}
return @{ $self->{local_c} }{ 'local_week_year', 'local_week_number' };
}
sub _local_weeks_in_year
{
my $self = shift;
my $year = shift;
#TODO: Later versions of DateTime optimise _weeks_in_year this is
copied from to something involving leap years and start days
#Possibly adapt that to include this optimisation
my $jan_one_dow =
#TODO: Older DateTime's have this as the presumably optimised (
( $self->_ymd2rd( $year, 1, 1 ) + 6 ) % 7 ) + 1;
#Work out how that needs translating to use the local day
( DateTime->new(year => $year, month => 1, day => 1, locale =>
$self->locale())->local_day_of_week() );
my $dec_31_dow =
#TODO: Older DateTime's have this as the presumably optimised (
( $self->_ymd2rd( $year, 12, 31 ) + 6 ) % 7 ) + 1;
#Work out how that needs translating to use the local day
( DateTime->new(year => $year, month => 12, day => 31, locale =>
$self->locale())->local_day_of_week() );
return $jan_one_dow == 4 || $dec_31_dow == 4 ? 53 : 52;
}
sub local_week_year { ( $_[0]->local_week )[0] }
sub local_week_number { ( $_[0]->local_week )[1] }Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.