sbeck-github / date-manip Goto Github PK

View Code? Open in Web Editor NEW

10.0 10.0 11.0 12.93 MB

License: Other

Perl 99.90% Shell 0.02% Batchfile 0.07% Roff 0.01% C 0.01%

date-manip's People

Contributors

Stargazers

Watchers

Forkers

manwar chorny haarg nosnilmot dallaylaen stigtsp lcacciari tbrowder wyrmiyu datamuc

date-manip's Issues

Typos: Date::Manip::Date

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

No entry in Changes for version 6.79

https://metacpan.org/source/SBECK/Date-Manip-6.79/Changes
I stumbled upon this while maintaining the perl modules repository for openSUSE.

TimeZone update request

Is is difficult to make a release to upgrade the Olsen TZ database file to 2018e?

Date::Manip::TZ::convert fails with strange error if input date in unexpected format

% 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.

Spelling error

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

TimeZone update request

Can you make a release with the Olsen 2020d database?

Issue when loading the Module: Use of uninitialized value $zone

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

Unable to determine TZ on NixOS

$ 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.

Question about Date::Manip::Recur::prev()

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.

"hence"

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.

Recurrences bug in v6.71

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.

TimeZone update request - 2021e

Can you make a release updating to 2021e?

missing windows timezone aliases

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

armv7l/Raspberry Pi 3: $now + 1 day == December 2015

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

Infinite loop for invalid frequency values in Date::Manip::Recur

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.

Example:

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.

Example code (perl 5.16.3):

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!

getting bogus output

$> perl
use Date::Manip qw(ParseDate);
print ParseDate("Nov, 2020"), "\n";
2020112000:00:00
$>

D::M timezoneinfo uses unreliable symlink filename

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;

Some Polish language abbreviations and names don't match Linux equivalents

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

Setup GitHub Actions

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.

Could you support TZ files?

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.

Updates for language files

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.

Explaining the Romanian Tuesday day_name update

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.

Parse failures

I'm including this section just FYI. None of this is causing me a problem. Just stuff I noticed.

Russian on macOS

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
%

German, Italian and Norwegian on Linux

German

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

Italian

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

Norwegian

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

Files

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

Use of uninitialized value $n in integer subtraction

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

perl 5.32.1
Date-Manip 6.85

Issue with Dates less than 24 and of specific pattern

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`

Question about D::M::Recur

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?

Date::Manip::Recur question

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).

Asia/Muscat Timezone is unrecognized

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.

Installation issues

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

Handling months

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;
}

Error parsing "1916apr23"

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).

printf format '%F' doesn't follow strftime

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? :)

Solaris 11 Sets TZ = localtime

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.

[windows] Unable to install Date::[email protected]: Detected circular dependency in graph at [blib\script\dm_date]

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.

Wrong Year for leap week

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)

RT: 64276, still marked "New"

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

cpanratings.perl.org no longer exists

This distribution has a link to CPAN Ratings at cpanratings.perl.org, but this address now redirects to https://metacpan.org/