sbeck-github / date-manip Goto Github PK
View Code? Open in Web Editor NEWLicense: Other
License: Other
VALID TIME ZONE FORMATS
When specifying a time zone, it can be done in three different ways. One
way is to specify the actual time zone. The second is to supply a valid
time zone abbreviation. The third is to specify an offset (with an
optional abbreviation). The following dates illustrate the these
formats.
The offset almost never sufficient to uniquely determine the time zone
https://metacpan.org/source/SBECK/Date-Manip-6.79/Changes
I stumbled upon this while maintaining the perl modules repository for openSUSE.
Is is difficult to make a release to upgrade the Olsen TZ database file to 2018e?
% perl -MDate::Manip::TZ -E '($err, $ref) = Date::Manip::TZ->new->convert("2020-07-29 13:30:00", "US/Central", "America/Chicago"); say @$ref'
Can't use an undefined value as an ARRAY reference at /usr/share/perl5/vendor_perl/Date/Manip/TZ.pm line 1587.
If you change the space character between date and time to -
then it works.
The error message should be better: "date and time string not in recognized format".
Also, since you already accept a handful of different formats, I think the regexps used could be a bit more tolerant and allow examples like the above.
Hello,
lintian (Debian quality tool) reports a spelling error. Here is a proposed patch:
--- a/lib/Date/Manip/TZ.pod
+++ b/lib/Date/Manip/TZ.pod
@@ -545,7 +545,7 @@
The local time zone is determined using the methods described in the
following section. The preferred way is to locate the time zone in
-some system file, or using some system command, or (in the case of
+some system files, or using some system commands, or (in the case of
a Windows operating system) to look it up in the registry. If all
of these methods fail, the local time zone may be set using either
the $::TZ or $ENV{TZ} variables. Please note that these should ONLY
Regards,
Xavier
Can you make a release with the Olsen 2020d database?
Hi,
I am trying to use Date::Manip on AIX 7.2. When performing a "use Date::Manip" I encounter a whole bunch of error messages:
[2]perl_ss@t72:/home/perl_ss $ perl -MDate::Manip -e 0
Use of uninitialized value $zone in lc at /home/perl_ss/perl5/lib/perl5/Date/Manip/TZ.pm line 199.
Use of uninitialized value $zone in concatenation (.) or string at /home/perl_ss/perl5/lib/perl5/Date/Manip/TZ.pm line 1341.
ERROR: [date_period] Invalid zone:
Use of uninitialized value $z in lc at /home/perl_ss/perl5/lib/perl5/Date/Manip/TZ.pm line 943.
ERROR: Date::Manip unable to determine Time Zone.
ERROR LOADING MODULE: Date::Manip::DM6 at /home/perl_ss/perl5/lib/perl5/Date/Manip.pm line 35.
Compilation failed in require.
BEGIN failed--compilation aborted.
I am using Version 6.57 of Date::Manip
DB<2> x $Date::Manip::VERSION
0 6.57
I am using the DM5 Interface in my scripts.
Is this normal behaviour? It seems odd to me. If you need any further information I will happily provide it.
Cheers,
Sandra
$ perl -MDate::Manip
ERROR: Date::Manip unable to determine Time Zone. GMT will be used.
ERROR: Date::Manip unable to determine Time Zone. GMT will be used.
This is due to Date/Manip/Tz.pm _init() not finding any of files or absoilute commands listed under Unix.
I'm trying to get the first occurence of a recurring event before a given date.
Here is the code that I tried :
$recur = new Date::Manip::Recur;
$recur->parse('0:1*2:2:0:0:0', undef, '28 aug 2017');
($prev, $err) = $recur->prev();
This should get "2nd Tuesday of every month" before the 28 aug 2017, which is the 8th of august.
But this code return the 11th of july, for whatever reason it goes straight to the previous month.
Am I missing something here, is there a way to do what I'm trying to do (get the first occurence before a given date) ?
Thanks.
ParseDate
understands '10 days ago'
. I think it would be useful to understand '10 days hence'
.
I know it will accept a plain '10 days'
with the same meaning but the expression '10 days hence'
is moderately clearer.
Release 6.71 of Date::Manip seems to have a bug in recurrences.
This worked prior to v6.71:
ParseRecur('0:0:0:0:1*0:0', '1 days ago', '0:0:0:0:-23:59:59', '4 days later');
But starting in 6.71, this no longer generates recurrences, and it does not set any error value either.
Bisecting shows this broke in 1204e93
This breaks the Log::Dispatch::FileRotate
for example.
Can you make a release updating to 2021e?
Hi,
on a finish machine the timezone is "FLE Standard Time". Date::Manip didn't like that. It looks like there are some aliases defined in Date::Manip::Zones. I created a list with tzutil /l
of all the timezones windows knows of. Here is a list of missing aliases:
danielt@lehn:~/vc/git/Date-Manip ‹master›
$ (while IFS= read line ; do fgrep -qi "$line" lib/Date/Manip/Zones.pm || echo "$line"; done < ~/tmp/tzutil.txt ) > missing.txt
danielt@lehn:~/vc/git/Date-Manip ‹master›
$ sort missing.txt
aleutian standard time
altai standard time
astrakhan standard time
aus central w. standard time
belarus standard time
bougainville standard time
chatham islands standard time
cuba standard time
easter island standard time
eastern standard time (mexico)
fle standard time
greenwich standard time
haiti standard time
libya standard time
line islands standard time
lord howe standard time
magallanes standard time
marquesas standard time
norfolk standard time
north korea standard time
omsk standard time
pacific standard time (mexico)
qyzylorda standard time
saint pierre standard time
sakhalin standard time
sao tome standard time
saratov standard time
south sudan standard time
sudan standard time
tocantins standard time
tomsk standard time
transbaikal standard time
turks and caicos standard time
volgograd standard time
w. mongolia standard time
west bank standard time
yukon standard time
On a Raspberry Pi 3 using Archlinux ARM I'm getting a date 13 years back for 'now + 1 day':
$ perl -MDate::Manip -le '$now = ParseDate("now");
print $now;
print DateCalc($now, "+1 day");'
2018062522:11:23
2005121322:11:23
$ perl -MDate::Manip=9999
Date::Manip version 9999 required--this is only version 6.72 at /usr/share/perl5/core_perl/Exporter/Heavy.pm line 125.
BEGIN failed--compilation aborted.
$ perl -V
Summary of my perl5 (revision 5 version 26 subversion 2) configuration:
Platform:
osname=linux
osvers=4.14.29-1-arch
archname=armv7l-linux-thread-multi
uname='linux leming 4.14.29-1-arch #1 smp preempt fri mar 23 02:57:06 utc 2018 armv7l gnulinux '
config_args='-des -Dusethreads -Duseshrplib -Doptimize=-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -O2 -pipe -fstack-protector-strong -fno-plt -Dprefix=/usr -Dvendorprefix=/usr -Dprivlib=/usr/share/perl5/core_perl -Darchlib=/usr/lib/perl5/5.26/core_perl -Dsitelib=/usr/share/perl5/site_perl -Dsitearch=/usr/lib/perl5/5.26/site_perl -Dvendorlib=/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib/perl5/5.26/vendor_perl -Dscriptdir=/usr/bin/core_perl -Dsitescript=/usr/bin/site_perl -Dvendorscript=/usr/bin/vendor_perl -Dinc_version_list=none -Dman1ext=1perl -Dman3ext=3perl -Dlddlflags=-shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Dldflags=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
hint=recommended
useposix=true
d_sigaction=define
useithreads=define
usemultiplicity=define
use64bitint=undef
use64bitall=undef
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
Compiler:
cc='cc'
ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
optimize='-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -O2 -pipe -fstack-protector-strong -fno-plt'
cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
ccversion=''
gccversion='7.3.1 20180312'
gccosandvers=''
intsize=4
longsize=4
ptrsize=4
doublesize=8
byteorder=1234
doublekind=3
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=8
longdblkind=0
ivtype='long'
ivsize=4
nvtype='double'
nvsize=8
Off_t='off_t'
lseeksize=8
alignbytes=8
prototype=define
Linker and Libraries:
ld='cc'
ldflags ='-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector-strong -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/7.3.1/include-fixed /usr/lib /lib
libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
libc=libc-2.26.so
so=so
useshrplib=true
libperl=libperl.so
gnulibc_version='2.26'
Dynamic Linking:
dlsrc=dl_dlopen.xs
dlext=so
d_dlsymun=undef
ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.26/core_perl/CORE'
cccdlflags='-fPIC'
lddlflags='-shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -L/usr/local/lib -fstack-protector-strong'
Characteristics of this binary (from libperl):
Compile-time options:
HAS_TIMES
MULTIPLICITY
PERLIO_LAYERS
PERL_COPY_ON_WRITE
PERL_DONT_CREATE_GVSV
PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP
PERL_OP_PARENT
PERL_PRESERVE_IVUV
USE_ITHREADS
USE_LARGE_FILES
USE_LOCALE
USE_LOCALE_COLLATE
USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC
USE_LOCALE_TIME
USE_PERLIO
USE_PERL_ATOF
USE_REENTRANT_API
Built under linux
Compiled at Apr 20 2018 22:02:24
@INC:
/usr/lib/perl5/5.26/site_perl
/usr/share/perl5/site_perl
/usr/lib/perl5/5.26/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib/perl5/5.26/core_perl
/usr/share/perl5/core_perl
Hi,
While using Date::Manip::Recur I have found that invalid values (not syntax) in a frequency string are not controlled, which breaks the calculation of recurring events.
I have been able to test it in two versions with different results: current 6.54 version and older 6.43.
I'm aware that 6.43 is quite old, but it could help you reproduce the error.
For the frequency string: '0:1*1,4,7:0:0:0:0'
(there's no week 7)
With any base date and range.
When calling $recur->next();
.
Using version 6.43, dies with:
Use of uninitialized value $n in integer subtraction (-) at Date/Manip/Recur.pm line 763.
Using version 6.54, falls in an infinite loop with output:
Use of uninitialized value $beg in string comparison (cmp) at Date/Manip/TZ.pm line 1355.
Use of uninitialized value $end in string comparison (cmp) at Date/Manip/TZ.pm line 1357.
use Date::Manip::Recur;
my $recur = new Date::Manip::Recur;
$recur->parse( '0:1*1,4,7:0:0:0:0' );
$recur->basedate( '2016-06-06T16:00:00' );
$recur->start( '2016-06-06T16:00:00' );
$recur->end( '2019-06-06T16:00:00' );
$recur->next();
Is there any way to control invalid frequencies like this one?
Thanks!
$> perl
use Date::Manip qw(ParseDate);
print ParseDate("Nov, 2020"), "\n";
2020112000:00:00
$>
Having a docker container which mounts host /etc/localtime into the container /etc/localtime to sync timezone information. Now docker follows the symlink and mounts the hosts localtime (which is CET) onto /usr/share/zoneinfo/UTC ending in a zoneinfo file named UTC but containing CET data.
Linux date
behaves correctly and tells the correct time, date and zone.
%> date +"%s - %Y-%m-%d %H:%M:%S %z"
1529498671 - 2018-06-20 14:44:31 +0200
Using D::M tells me:
%> DATE_MANIP_DEBUG=1 perl -MDate::Manip -e 'print UnixDate("now", "%s - %Y-%m-%d %H:%M:%S %z"),"\n";'
*** DEBUG *** METHOD: main [TZ] undef
*** DEBUG *** METHOD: env [zone,TZ] undef
*** DEBUG *** METHOD: file [/etc/TIMEZONE] not found
*** DEBUG *** METHOD: file [/etc/timezone] not found
*** DEBUG *** METHOD: file [/etc/sysconfig/clock] not found
*** DEBUG *** METHOD: file [/etc/default/init] not found
*** DEBUG *** METHOD: tzdata [/etc/localtime /usr/share/zoneinfo] UTC
*** DEBUG *** METHOD: main [TZ] undef
*** DEBUG *** METHOD: env [zone,TZ] undef
*** DEBUG *** METHOD: file [/etc/TIMEZONE] not found
*** DEBUG *** METHOD: file [/etc/timezone] not found
*** DEBUG *** METHOD: file [/etc/sysconfig/clock] not found
*** DEBUG *** METHOD: file [/etc/default/init] not found
*** DEBUG *** METHOD: tzdata [/etc/localtime /usr/share/zoneinfo] UTC
1529505873 - 2018-06-20 14:44:33 +0000
So the time is correct, but the unix timestamp and zone is wrong. I guess looking at the filename instead of the file content is for performance reasons. But on the other hand, those zonefiles are pretty small, so it shouldn't have much of an impact.
Uncommenting this line helps:
https://github.com/SBECK-github/Date-Manip/blame/master/lib/Date/Manip/TZ.pm#L108
Since timezone is then correctly detected by date +%Z
command.
Other workaround would be to set $ENV{'TZ'} = date +%Z
;
I've had some difficulty recognising Polish dates on Linux. It seems to be due to a difference between the abbreviations and one month name in the Date::Manip::Lang file polish.pm and those that Linux uses in date(1) and strftime(3).
I'm wondering if there is a reason for the current values being as they are, or if they could be updated to fix the parsing on Linux.
Weekdays
The day abbreviations are currently
day_abb => [
['po', 'po.', 'pon.', 'pon'],
['wt', 'wt.'],
['śr', 'śr.', 'sr.', 'sr'],
['cz', 'cz.', 'czw.', 'czw'],
['pi', 'pi.'],
['so', 'so.'],
['ni', 'ni.'],
],
When I test using those values, I get the following result, and the blank output lines are failed parses:
% perl -MDate::Manip -lpe 'Date_Init("Language=Polish", "DateFormat=non-US"); $_=UnixDate(ParseDate($_), "%Y%m%d %T")'
pon 26 wrz 13:11:28 2022 AEST
wto 27 wrz 14:11:28 2022 AEST
śro 28 wrz 15:11:28 2022 AEST
czw 29 wrz 16:11:28 2022 AEST
ptk 30 wrz 17:11:28 2022 AEST
sob 24 wrz 11:11:28 2022 AEST
ndz 25 wrz 12:11:28 2022 AEST
20220926 13:11:28
20220929 16:11:28
%
If I update the day abbreviations to these values to allow for the 3-letter abbreviations that Linux uses
day_abb => [
['po', 'po.', 'pon.', 'pon'],
['wt', 'wt.', 'wto', 'wto.'],
['śr', 'śr.', 'sr.', 'sr', 'śro', 'śro.', 'sro.', 'sro'],
['cz', 'cz.', 'czw.', 'czw'],
['pi', 'pi.', 'ptk', 'ptk.'],
['so', 'so.', 'sob', 'sob.'],
['ni', 'ni.', 'ndz', 'ndz.'],
],
and rerun the test, all dates parse:
% perl -MDate::Manip -lpe 'Date_Init("Language=Polish", "DateFormat=non-US"); $_=UnixDate(ParseDate($_), "%Y%m%d %T")'
pon 26 wrz 13:11:28 2022 AEST
wto 27 wrz 14:11:28 2022 AEST
śro 28 wrz 15:11:28 2022 AEST
czw 29 wrz 16:11:28 2022 AEST
ptk 30 wrz 17:11:28 2022 AEST
sob 24 wrz 11:11:28 2022 AEST
ndz 25 wrz 12:11:28 2022 AEST
20220926 13:11:28
20220927 14:11:28
20220928 15:11:28
20220929 16:11:28
20220930 17:11:28
20220924 11:11:28
20220925 12:11:28
%
Would those values be acceptable to add to the configuration?
Months
The Polish month name for February is configured as 'luty'. Linux uses 'lutego', which is a declension form of luty.
Could 'lutego' be added as an alternative?
regards - David
I am using the CPAN Digger to locate recently release modules that don't have a working CI system. As I can see all of your modules that has a link to their VCS have Travis CI which unfortunately has stopped providing free service.
If you are interested I'd be happy to send you PR to this and to your other CPAN modules configuring Github Actions.
I know you've stated that you would not like to support TZ files in Date::Manip doc. But I would still like to bring this thing up.
I raised a similar ticket to DateTime::TimeZone houseabsolute/DateTime-TimeZone#33
I believe it's a common thing in Enterprises, that Linux systems /usr/share/zoneinfo can be well kept up-to-date, while a deployed Perl code might not easily get its dependencies updated. In this case the CPAN package bundled Olson data could become outdated over time and cause problems. So it's best if the Perl timezone library can provide a way to allow user to use OS platform's Olson data like /usr/share/zoneinfo.
This is a follow-on from #41. I initially posted the comments below to that closed issue, which I couldn't re-open. They really warrant a separate issue, as #41 is related only to the Polish language. I'll delete the original comments on #41 after posting in this issue.
I've attached 8 files named <language>_new.pm.txt. They are the merge of changes required to parse dates on MacOS Monterey 12.5.1 and Oracle Linux Server 7.9. I appended .txt to permit attachment. There are some parse failures I note below.
I've also attached two crude scripts I used to test all the language configuration files, date-manip-test-macos.sh.txt and date-manip-test-linux.sh.txt. They aren't ideal tests, as they will fail to parse a date if, for example, either a day abbreviation or a month abbreviation isn't recognised. When all date time elements are recognised, they parse, which is how I used them. I ran both scripts with the final merged language files.
I'm not a speaker of any of these languages, so I simply updated the files to achieve successful parsing, using the strings output by date(1).
Do you know yet what the version number will be that incorporates changes? I'll look for it downstream.
I added an entry to the Romanian Tuesday array, the last element below, which both Linux and macOS output as the full day name:
['marți', 'marti', 'marþi', 'marţi'],
The ț in the first element is U+021B, Latin small letter t with comma below.
The ţ in the last element is U+0163, Latin small letter t with cedilla.
Both are accepted as Tuesday in Romanian, e.g. see reverso translation of both.
I'm including this section just FYI. None of this is causing me a problem. Just stuff I noticed.
The standard output of date on macOS fails to parse. It's due to the presence of "r. " and the parentheses around the TZ name in the output below. The blank line is the failed parse. Using a format to eliminate the "r. " and parentheses results in a successful parse.
% LANG=ru_RU date
четверг, 6 октября 2022 г. 18:34:30 (AEDT)
% LANG=ru_RU date | perl -I/Users/USERNAME/Downloads/Date-Manip-SBECK-github/lib/ -MDate::Manip -lpe 'Date_Init("Language=Russian", "DateFormat=non-US"); $_=UnixDate(ParseDate($_), "%Y%m%d %T")'
% LANG=ru_RU date +"%A, %e %B %Y %T %Z"
четверг, 6 октября 2022 18:35:53 AEDT
% LANG=ru_RU date +"%A, %e %B %Y %T %Z" | perl -I/Users/USERNAME/Downloads/Date-Manip-SBECK-github/lib/ -MDate::Manip -lpe 'Date_Init("Language=Russian", "DateFormat=non-US"); $_=UnixDate(ParseDate($_), "%Y%m%d %T")'
20221006 18:36:10
%
The default format doesn’t parse, with or without .UTF-8:
$ LANG=de_DE.UTF-8 date --date="2022-01-03 11:00:00"
Mo 3. Jan 11:00:00 AEST 2022
It appears to be due to the period after the day of the month. This does parse, with or without .UTF-8:
$ LANG=de_DE.UTF-8 date --date="2022-01-03 11:00:00" +"%a %e %b %Y %T %Z"
Mo 3 Jan 2022 11:00:00 AEST
The default format doesn’t parse, with or without .UTF-8:
$ LANG=it_IT.UTF-8 date --date="2022-01-03 11:00:00"
lun 3 gen 2022, 11.00.00, AEST
It appears to the due to the commas, and I didn't check whether the periods in the time contribute. This does parse, with or without .UTF-8:
$ LANG=it_IT.UTF-8 date --date="2022-01-03 11:00:00" +"%a %e %b %Y %T %Z"
lun 3 gen 2022 11:00:00 AEST
The default format doesn’t parse:
$ LANG=no_NO date --date="2022-01-03 11:00:00"
ma. 03. jan. 11:00:00 +1000 2022
It seems to be due to the period after the day of the month.
UTF-8 seems to output the default LANG (en_AU):
$ LANG=no_NO.UTF-8 date --date="2022-01-03 11:00:00"
Mon Jan 3 11:00:00 AEST 2022
This does parse without .UTF-8:
$ LANG=no_NO date --date="2022-01-03 11:00:00" +"%a %e %b %Y %T %Z"
ma. 3 jan. 2022 11:00:00 AEST
This doesn’t parse with .UTF-8, unless you use English, i.e. Date_Init("Language=English", "DateFormat=non-US")
:
$ LANG=no_NO.UTF-8 date --date="2022-01-03 11:00:00" +"%a %e %b %Y %T %Z"
Mon 3 Jan 2022 11:00:00 AEST
finnish_new.pm.txt
french_new.pm.txt
norwegian_new.pm.txt
polish_new.pm.txt
portugue_new.pm.txt
romanian_new.pm.txt
russian_new.pm.txt
turkish_new.pm.txt
date-manip-test-macos.sh.txt
date-manip-test-linux.sh.txt
When I have same start and end date, ->next
works fine and as expected, but generates unexpcepted and unwanted warning:
$ perl -MDate::Manip::Recur -E 'my $r = Date::Manip::Recur->new; $r->parse("0:0:0:*17:30:0"); $r->basedate("2015-06-01,");$r->start("2015-06-01,"); $r->end("2015-06-01,"); my ($date, $err) = $r->next ; say join (" ", $date->value )'
Use of uninitialized value $n in integer subtraction (-) at /home/foo/perl5/lib/perl5/Date/Manip/Recur.pm line 920.
2015 6 1 17 30 0
Version: 6.75
`use Date::Manip;
my $dateString = "October 23,2018";
my $date = ParseDate($dateString);
print $date;
No output
use Date::Manip;
my $dateString = "October 24,2018";
my $date = ParseDate($dateString);
print $date;
2018102400:00:00`
I dont know if this is the right place to ask, but here goes.
I am trying to implement the Data::Manip::Recur definition for New Zealands 'Auckland Anniversary Day' (and other anniversary days, which follow a similar selection criteria).
The criteria is "Monday nearest to 29th", either before or after and can be in Feb. Lots of details at http://www.officeholidays.com/countries/new_zealand/auckland_provincial.php
This line seems to work for some years but not all:
1*1:0:29:0:0:0*NWD,IW1 = Auckland Anniversary Day
It successfully predicts 2017-01-30 & 2018-01-29, but not others.
Im not surpised it doesnt select dates prior as it is Next Working Day, but it doesnt select 2016-02-01 which is the next working day and is a monday. I suspect that because its in Feb its being ignored?
I have attempted to add more selectors on the end to go backwards but havent succeeded in matching any dates other than 2017 and 2018
Please help?
I'm using date() on a Date::Manip::Recur to retrieve some occurences of a recurring event.
Here is my example :
my $recur = new Date::Manip::Recur;
my $err = $recur->parse('*1990-1995:12:0:1:0:0:0');
my @dates = $recur->dates('1992-01-01', '1994-12-31');
It works well if I don't specify the range when calling dates(), but in my case I want them to be within a specifc sub-range (1992 to 1994).
Even with v6.89 I see:
ERROR: Date::Manip unable to determine Time Zone. GMT will be used. at /usr/local/share/perl5/Date/Manip/DM6.pm line 65.
ERROR: Date::Manip unable to determine Time Zone. GMT will be used. at /usr/local/share/perl5/Date/Manip/DM6.pm line 68.
I'm trying to install a perl module that depends on Manip, but after installing Manip keeps giving an error like
Can't locate package Date::Manip::Obj for @Date::Manip::TZ::ISA at /export/home/....
MANIP VERSION: Date-Manip-6.60
Perl: v5.22.3
It would be really nice if this code printed 1786, instead of 1986.
#!/usr/bin/env perl
use Date::Manip;
print get_year_from_date('Feb 1786'), "\n";
sub get_year_from_date()
{
my $date = shift;
my $year = UnixDate(ParseDate($date), "%Y");
return $year if($year);
die;
}
However "1916apr22" and "1916apr24" parse correctly. What is so special about "1916apr23"?
This problem affects every version of Date:Manip that I checked, on 5 distinct systems.
Date::Manip 6.76 (Debian 10, perl v5.28.1)
Date::Manip 6.60 (Red Hat Enterprise Linux 8.5, perl v5.26.3; and also CentOS Linux 8, perl v5.26.3)
Date::Manip 6.41 (CentOS Linux 7, perl v5.16.3)
Date::Manip 6.24 (Red Hat Enterprise Linux 6.10, perl v5.10.1).
While updating my code to work around issues I encountered with the v6 functional interface and converting to using the OO interface, I switched from how I was using the following code path to calculate an offset and then format for output:
my $time = DataCalc($date, $offset);
$time = UnixDate($time, '%s');
@tm = localtime($time);
$result = strftime($format, @tm);
Latest perl and Date::Manip modules was causing this code to return the wrong date when trying to add 24 hours to a date and have it just spit out YYYY-MM-DD. I was using '%F' as strftime spits out the format in question.
Converting the above code to use your OO interface gives me the correct date now but '%F' isn't what I'm expecting so I have to spell out '%Y-%m-%d' as the format, which was a nasty surprise.
my $dmObj = Date::Manip::Date->new();
my $deltaObj = Date::Manip::Delta->new();
my $err = $dmObj->parse($date);
if ($err) {
logger->error("getDateOffset(): failed to parse date='$date'. err='$err'");
return '';
}
$deltaObj->parse($offset);
my $new_date = $dmObj->calc($deltaObj);
my $result = $new_date->printf($format);
I guess there's 2 issues here. Why does the above functional code no longer work? I'm assuming it's got something to do with your TZ changes.
Where'd your version of '%F' come from? :)
When you load the module on solaris 11 you receive the following messages
"Use of uninitialized value $zone in lc at /pkg/fsadmin/lib/perl/solaris11/5.22/lib/perl5/Date/Manip/TZ.pm line 199.
Use of uninitialized value $zone in concatenation (.) or string at /pkg/fsadmin/lib/perl/solaris11/5.22/lib/perl5/Date/Manip/TZ.pm line 1341.
ERROR: [date_period] Invalid zone:
Use of uninitialized value $z in lc at /pkg/fsadmin/lib/perl/solaris11/5.22/lib/perl5/Date/Manip/TZ.pm line 943."
From what I can tell the module initializes and looks for a valid Timezone from various places. Once place is the environmental variable TZ, which in solaris 11 is set to TZ=localtime. This of course is not a valid timezone, but this is how solaris 11 sets it by default no matter what time zone it is set to.
cpanm -n Date::[email protected]
--> Working on Date::Manip
Fetching http://www.cpan.org/authors/id/S/SB/SBECK/Date-Manip-6.87.tar.gz ... OK
Configuring Date-Manip-6.87 ... OK
Building Date-Manip-6.87 ... FAIL
! Finding Date::Manip (== 6.87) on cpanmetadb failed.
! Installing Date::Manip failed. See C:\Users\ADMINI~1\.cpanm\work\1654147724.2784\build.log for details. Retry with --force to force install it.
Contents of the log
cpanm (App::cpanminus) 1.7040 on perl 5.020003 built for MSWin32-x86-multi-thread-64int
Work directory is C:\Users\ADMINI~1/.cpanm/work/1654147724.2784
You have make C:\Strawberry\c\bin\dmake.exe
You have LWP 6.15
Falling back to Archive::Tar 2.04
Searching Date::Manip (== 6.87) on cpanmetadb ...
-> FAIL Finding Date::Manip (== 6.87) on cpanmetadb failed.
Searching Date::Manip (== 6.87) on metacpan ...
! Could not find a release matching Date::Manip (== 6.87) on MetaCPAN.
Searching Date::Manip on mirror http://www.cpan.org ...
Downloading index file http://www.cpan.org/modules/02packages.details.txt.gz ...
--> Working on Date::Manip
Fetching http://www.cpan.org/authors/id/S/SB/SBECK/Date-Manip-6.87.tar.gz
-> OK
Unpacking Date-Manip-6.87.tar.gz
Entering Date-Manip-6.87
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.67_01 ... Yes (7.10)
Configuring Date-Manip-6.87
Running Makefile.PL
Checking if your kit is complete...
Warning: the following files are missing in your kit:
lib/Date/Manip/.Changes6.pod.swp
pm_to_blib
Please inform the author.
Generating a dmake-style Makefile
Writing Makefile for Date::Manip
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have Storable 0 ... Yes (2.51)
Checking if you have Data::Dumper 0 ... Yes (2.154)
Checking if you have utf8 0 ... Yes (1.13_01)
Checking if you have Win32::TieRegistry 0.28 ... Yes (0.30)
Checking if you have Carp 0 ... Yes (1.38)
Checking if you have File::Find 0 ... Yes (1.27)
Checking if you have File::Spec 0 ... Yes (3.62)
Checking if you have IO::File 0 ... Yes (1.16)
Checking if you have Cwd 0 ... Yes (3.62)
Checking if you have Encode 0 ... Yes (2.82)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.10)
Building Date-Manip-6.87
dmake.exe: makefile: line 3178: Error: -- Detected circular dependency in graph at [blib\script\dm_date]
-> FAIL Installing Date::Manip failed. See C:\Users\ADMINI~1\.cpanm\work\1654147724.2784\build.log for details. Retry with --force to force install it.
platform is Microsoft Windows [Version 6.3.9600]
As a workaround, we have pinned 6.86 until this issue can be resolved.
Hi,
i believe to have found a bug regarding the year in a leap week.
In my example I'm getting the current year and not the last one.
In my opinion it should be the last year for the weak 53.
Code:
use Date::Manip;
use Data::Dumper;
my $date = &ParseDateString("2021-01-03");
print Dumper UnixDate($date, "%Y%W");
Result:
$VAR1 = '202153';
Expected Result:
$VAR1 = '202053';
Date::Manip-Version:
6.60 [europe/berlin]
Perl Version:
This is perl 5, version 26, subversion 3 (v5.26.3) built for x86_64-linux-thread-multi
(with 51 registered patches)
Hi,
I noticed an issue raised in RT: 64276 on Dec 28, 2010 and status "New". However looking at the source code, it should have been resolved now. It would be nice to clear the issue that is fixed.
https://rt.cpan.org/Ticket/Display.html?id=64276
Many Thanks.
Best Regards,
Mohammad S Anwar
This distribution has a link to CPAN Ratings at cpanratings.perl.org, but this address now redirects to https://metacpan.org/
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.