Originally posted by: Edward Davignon

I have been having a lot of trouble debugging a program to parse a date-time stamps and calculate expiration dates on AIX in Perl. I believe there is a bug in handling time zones in Perl that ships with AIX. What is the correct behavior of %z in Time::Piece->strptime? What are the correct behaviors of %Z and %z of strftime in Time::Piece? Why does strftime in Time::Piece report time zones differently when a format string is supplied and when it is called without any attributes? I understand that %Z in strftime should print an abbreviated time zone name and %z in strftime should print a numeric time zone offset.

Here is a simple demonstration of one of the problems I am having.

aixserver$ /usr/opt/perl5/bin/perl5.20.1_64bit testcase.pl
$dt->strftime() is 'Mon, 05 Oct 2015 13:34:19 UTC'
$dt->strftime('%Y%m%d%H%M %Z') is '201510051334 EST'
$dt->strftime('%Y%m%d%H%M %z') is '201510051334 EST'
$dt->tzoffset is '0'
$ENV{TZ} is 'America/New_York'
aixserver$ /opt/freeware/bin/perl_64bit testcase.pl
$dt->strftime() is 'Mon, 05 Oct 2015 13:34:19 UTC'
$dt->strftime('%Y%m%d%H%M %Z') is '201510051334 UTC'
$dt->strftime('%Y%m%d%H%M %z') is '201510051334 +0000'
$dt->tzoffset is '0'
$ENV{TZ} is 'America/New_York'
aixserver$ cat testcase.pl
#!/usr/bin/perl

use Time::Piece;

my $datetime = '2015-10-05T09:34:19 -04:00';
$datetime =~ s/([+\-]\d\d):(\d\d)/$1$2/;
my $dt = Time::Piece->strptime($datetime, "%Y-%m-%dT%H:%M:%S %z");

my $format_Z = '%Y%m%d%H%M %Z';
my $format_z = '%Y%m%d%H%M %z';
print "\$dt->strftime() is '",$dt->strftime(),"'\n";
print "\$dt->strftime('$format_Z') is '", $dt->strftime($format_Z), "'\n";
print "\$dt->strftime('$format_z') is '", $dt->strftime($format_z), "'\n";
print "\$dt->tzoffset is '", $dt->tzoffset, "'\n";

print "\$ENV{TZ} is '$ENV{TZ}'\n";

aixserver$ oslevel -s
7200-03-03-1914
aixserver$ lslpp -l perl.rte
Fileset Level State Description
----------------------------------------------------------------------------
Path: /usr/lib/objrepos
perl.rte 5.20.1.3 COMMITTED Perl Version 5 Runtime
Environment
aixserver$ yum list perl
Loaded plugins: changelog, downloadonly
Installed Packages
perl.ppc 1:5.28.1-1 @AIX_Toolbox
aixserver$

# based on https://www.perl.com/article/59/2014/1/10/Solve-almost-any-datetime-need-with-Time--Piece/

Here is another problem with %z in strftime and a demonstration showing different behavior depending on how the time zone is specified (i.e. new() behaves differently than %z in strptime in above example):

aixserver$ /usr/opt/perl5/bin/perl5.20.1_64bit ./testcase2.pl
$dt->strftime() is 'Tue, 25 Jun 2019 14:23:43 EDT'
$dt->strftime('%Y%m%d%H%M %Z') is '201906251423 EDT'
$dt->strftime('%Y%m%d%H%M %z') is '201906251423 EDT'
$dt->tzoffset is '-14400'
$ENV{TZ} is 'America/New_York'
aixserver$ /opt/freeware/bin/perl5.28.1_64bit ./testcase2.pl
$dt->strftime() is 'Tue, 25 Jun 2019 14:23:57 EDT'
$dt->strftime('%Y%m%d%H%M %Z') is '201906251423 EDT'
$dt->strftime('%Y%m%d%H%M %z') is '201906251423 EDT'
$dt->tzoffset is '-14400'
$ENV{TZ} is 'America/New_York'
aixserver$ cat ./testcase2.pl
#!/usr/bin/perl

use Time::Piece;

my $dt = Time::Piece->new();

my $format_Z = '%Y%m%d%H%M %Z';
my $format_z = '%Y%m%d%H%M %z';
print "\$dt->strftime() is '",$dt->strftime(),"'\n";
print "\$dt->strftime('$format_Z') is '", $dt->strftime($format_Z), "'\n";
print "\$dt->strftime('$format_z') is '", $dt->strftime($format_z), "'\n";
print "\$dt->tzoffset is '", $dt->tzoffset, "'\n";
print "\$ENV{TZ} is '$ENV{TZ}'\n";

aixserver$

Originally posted by: AyappanP

We will check on this and will get back soon. 

Originally posted by: janhar

AIX SUPPORT CASE UPDATE: 

Hi, Edward - I'm copying the case info here so everyone has it!

I tested on 5.28 and I get:

$dt->strftime() is 'Mon, 05 Oct 2015 13:34:19 UTC'
$dt->strftime('%Y%m%d%H%M %Z') is '201510051334 UTC'


$dt->strftime('%Y%m%d%H%M %z') is '201510051334 +0000'
$dt->tzoffset is '0'
$ENV{TZ} is 'CST6CDT'

It seems they made changes to the sub strftime in Time:Piece (Time/Piece.pm version 1.3204) in 5.28  adding strftime_trans_map.

 

(Versus perl 5.20 Time/Piece.pm version 1.27)

 

I see that you had already opened the forum thread, and for these types of questions, the Open Source forum is the correct support venue for such questions, as this is not an "AIX" issue, but a difference in Perl releases. Technically, it may be a better choice to raise the questions on the Perl forum, but that is something the IBM Open Source Community can advise about.

 

I did want to copy the info I shared in your case, regarding updating the current AIX perl.rte 

 

We ship perl.rte on AIX in order to provide internal perl support for AIX applications. It was never intended to be used as production for our customers, because it would typically be an older release, due to the release cycle time frame for an AIX release prior to GA.

 

AIX does not back port fixes from a later perl release, nor do we update the version via a "fix" because it could break AIX components which were written and tested on the version shipped. We will eventually ship the next available stable release which is built, tested, and maintained on the AIX Toolbox for Linux Applications.

 

I hope this explanation helps. Please follow this thread, and of course check out the Perl communities (especially Perl Monks) https://www.perl.org/community.html

 

Originally posted by: AyappanP

AIX strptime doesn't seems to support %z format specifier. Man page shows nothing about it. 

AIX strftime supports %z format specifier. It should represent the numerical offset from UTC. So i think there is definitely a problem here. It's showing timezone instead of numerical offset which is not correct. 

 

Originally posted by: T.Rex

See: https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/s_bostechref/strftime.html

%z

Represents the offset from Coordinated Universal Time (UTC) in the ISO 8601 format −0430 means 4 hours 30 minutes behind UTC, west of Greenwich, or by no characters if you can not determine the time zone [tm_isdst]. Note You must set the value of the XPG_SUS_ENV=ON environment variable to use the %z option else it falls back to the %Z option.

Hope it helps.

Originally posted by: AyappanP

Great !!! 

"export XPG_SUS_ENV=ON" made it work. 

 

 

Originally posted by: Edward Davignon

Could this be done at compile time for the perl executables?  Perhaps setting _POSIX_C_SOURCE or _XOPEN_SOURCE to a particular value?

I am looking at /usr/include/standards.h and /usr/include/unistd.h

Since XPG_SUS_ENV is not set by default, it may cause problems with other OS components or other application binaries.  XPG_SUS_ENV is used to enable conformance with newer UNIX standards, but may break things tested against the older, backward compatible libraries.

Originally posted by: Edward Davignon

T.Rex, thanks for pointing out the XPG_SUS_ENV note in the strftime manual for AIX.

Originally posted by: Edward Davignon

Converting days into seconds while observing all of the leap-year days, known implementation bugs, and ever-changing conventions for leap seconds and daylight-savings-time is maddening!

 

Does anyone have a simple, pure-Perl library or function that correctly calculates differences of proleptic Gregorian calendar dates?

See: https://en.wikipedia.org/wiki/ISO_8601#Dates

 

 

Here are a few of the things I have run into.

 

Watch out for libraries that assume year 1970 (or 1900) have the same daylight saving time transition dates (and number of leap-year days) as the current year:

 

aixserver$ echo "===>$TZ<==="

===>America/New_York<===

aixserver$ zdump -V -c 1969,1971 "$TZ"

America/New_York Sun Apr 27 06:59:59 1969 UT = Sun Apr 27 01:59:59 1969 EST isdst=0 gmtoff=-18000

America/New_York Sun Apr 27 07:00:00 1969 UT = Sun Apr 27 03:00:00 1969 EDT isdst=1 gmtoff=-14400

America/New_York Sun Oct 26 05:59:59 1969 UT = Sun Oct 26 01:59:59 1969 EDT isdst=1 gmtoff=-14400

America/New_York Sun Oct 26 06:00:00 1969 UT = Sun Oct 26 01:00:00 1969 EST isdst=0 gmtoff=-18000

America/New_York Sun Apr 26 06:59:59 1970 UT = Sun Apr 26 01:59:59 1970 EST isdst=0 gmtoff=-18000

America/New_York Sun Apr 26 07:00:00 1970 UT = Sun Apr 26 03:00:00 1970 EDT isdst=1 gmtoff=-14400

America/New_York Sun Oct 25 05:59:59 1970 UT = Sun Oct 25 01:59:59 1970 EDT isdst=1 gmtoff=-14400

America/New_York Sun Oct 25 06:00:00 1970 UT = Sun Oct 25 01:00:00 1970 EST isdst=0 gmtoff=-18000

aixserver$ zdump -V -c 2018,2020 "$TZ"

America/New_York Sun Mar 11 06:59:59 2018 UT = Sun Mar 11 01:59:59 2018 EST isdst=0 gmtoff=-18000

America/New_York Sun Mar 11 07:00:00 2018 UT = Sun Mar 11 03:00:00 2018 EDT isdst=1 gmtoff=-14400

America/New_York Sun Nov 4 05:59:59 2018 UT = Sun Nov 4 01:59:59 2018 EDT isdst=1 gmtoff=-14400

America/New_York Sun Nov 4 06:00:00 2018 UT = Sun Nov 4 01:00:00 2018 EST isdst=0 gmtoff=-18000

America/New_York Sun Mar 10 06:59:59 2019 UT = Sun Mar 10 01:59:59 2019 EST isdst=0 gmtoff=-18000

America/New_York Sun Mar 10 07:00:00 2019 UT = Sun Mar 10 03:00:00 2019 EDT isdst=1 gmtoff=-14400

America/New_York Sun Nov 3 05:59:59 2019 UT = Sun Nov 3 01:59:59 2019 EDT isdst=1 gmtoff=-14400

America/New_York Sun Nov 3 06:00:00 2019 UT = Sun Nov 3 01:00:00 2019 EST isdst=0 gmtoff=-18000

aixserver$ zdump -v -c 1890,1919 "$TZ"

America/New_York Fri Dec 13 20:45:52 1901 UT = Fri Dec 13 15:45:52 1901 EST isdst=0 gmtoff=-18000

America/New_York Sat Dec 14 20:45:52 1901 UT = Sat Dec 14 15:45:52 1901 EST isdst=0 gmtoff=-18000

America/New_York Sun Mar 31 06:59:59 1918 UT = Sun Mar 31 01:59:59 1918 EST isdst=0 gmtoff=-18000

America/New_York Sun Mar 31 07:00:00 1918 UT = Sun Mar 31 03:00:00 1918 EDT isdst=1 gmtoff=-14400

America/New_York Sun Oct 27 05:59:59 1918 UT = Sun Oct 27 01:59:59 1918 EDT isdst=1 gmtoff=-14400

America/New_York Sun Oct 27 06:00:00 1918 UT = Sun Oct 27 01:00:00 1918 EST isdst=0 gmtoff=-18000

America/New_York Mon Jan 18 03:14:07 2038 UT = Sun Jan 17 22:14:07 2038 EST isdst=0 gmtoff=-18000

America/New_York Tue Jan 19 03:14:07 2038 UT = Mon Jan 18 22:14:07 2038 EST isdst=0 gmtoff=-18000

aixserver$

 

 

Watch out for the 1900-leap-year bug in Lotus 123 and inherited in MS Excel spreadsheet epochs calculations:

 

aixserver$ LANG=C TZ=UTC /opt/freeware/bin/date --date='12:00 Feb 28, 2000'

Mon Feb 28 12:00:00 UTC 2000

aixserver$ LANG=C TZ=UTC /opt/freeware/bin/date --date='12:00 Feb 29, 2000'

Tue Feb 29 12:00:00 UTC 2000

aixserver$ LANG=C TZ=UTC /opt/freeware/bin/date --date='12:00 Feb 28, 1900'

Wed Feb 28 12:00:00 UTC 1900

aixserver$ LANG=C TZ=UTC /opt/freeware/bin/date --date='12:00 Feb 29, 1900'

date_64: invalid date '12:00 Feb 29, 1900'

aixserver$

 

Note: 2000 is divisible by 400, so it is a leap year. While 1900 is divisible by 4, but not 400; so 1900 is not a leap year on the Gregorian calendar.

 

 

Watch out for date calculations that cross leap days:

 

aixserver$ LANG=C /opt/freeware/bin/date --date='TZ="America/New_York" 12:00 July 29, 1900 6 months ago'

Mon Jan 29 12:00:00 EST 1900

aixserver$ LANG=C /opt/freeware/bin/date --date='TZ="America/New_York" 12:00 July 29, 1900 5 months ago'

Thu Mar 1 12:00:00 EST 1900

aixserver$

 

aixserver$ LANG=C TZ=EST5EDT /opt/freeware/bin/date --date='TZ="EST5EDT" 12:00 July 29, 2000 6 months ago'

Sat Jan 29 12:00:00 EST 2000

aixserver$ LANG=C TZ=EST5EDT /opt/freeware/bin/date --date='TZ="EST5EDT" 12:00 July 29, 2000 5 months ago'

Tue Feb 29 12:00:00 EST 2000

aixserver$ LANG=C TZ=EST5EDT /opt/freeware/bin/date --date='TZ="EST5EDT" 12:00 July 29, 1900 6 months ago'

Mon Jan 29 12:00:00 EST 1900

aixserver$ LANG=C TZ=EST5EDT /opt/freeware/bin/date --date='TZ="EST5EDT" 12:00 July 29, 1900 5 months ago'

Thu Mar 1 12:00:00 EST 1900

aixserver$ rpm -qf /opt/freeware/bin/date

coreutils-8.29-3.ppc

aixserver$ yum list | grep coreutils

coreutils.ppc 8.29-3 @AIX_Toolbox

aixserver$

 

 

Watch out for the Y2K and 2038 problems.

 

aixserver$ echo "===>$TZ<==="

===>America/New_York<===

aixserver$ zdump -v -c 1999,2001 "$TZ"

America/New_York Fri Dec 13 20:45:52 1901 UT = Fri Dec 13 15:45:52 1901 EST isdst=0 gmtoff=-18000

America/New_York Sat Dec 14 20:45:52 1901 UT = Sat Dec 14 15:45:52 1901 EST isdst=0 gmtoff=-18000

America/New_York Sun Apr 4 06:59:59 1999 UT = Sun Apr 4 01:59:59 1999 EST isdst=0 gmtoff=-18000

America/New_York Sun Apr 4 07:00:00 1999 UT = Sun Apr 4 03:00:00 1999 EDT isdst=1 gmtoff=-14400

America/New_York Sun Oct 31 05:59:59 1999 UT = Sun Oct 31 01:59:59 1999 EDT isdst=1 gmtoff=-14400

America/New_York Sun Oct 31 06:00:00 1999 UT = Sun Oct 31 01:00:00 1999 EST isdst=0 gmtoff=-18000

America/New_York Sun Apr 2 06:59:59 2000 UT = Sun Apr 2 01:59:59 2000 EST isdst=0 gmtoff=-18000

America/New_York Sun Apr 2 07:00:00 2000 UT = Sun Apr 2 03:00:00 2000 EDT isdst=1 gmtoff=-14400

America/New_York Sun Oct 29 05:59:59 2000 UT = Sun Oct 29 01:59:59 2000 EDT isdst=1 gmtoff=-14400

America/New_York Sun Oct 29 06:00:00 2000 UT = Sun Oct 29 01:00:00 2000 EST isdst=0 gmtoff=-18000

America/New_York Mon Jan 18 03:14:07 2038 UT = Sun Jan 17 22:14:07 2038 EST isdst=0 gmtoff=-18000

America/New_York Tue Jan 19 03:14:07 2038 UT = Mon Jan 18 22:14:07 2038 EST isdst=0 gmtoff=-18000

aixserver$ lslpp -l bos.rte.date

Fileset Level State Description

----------------------------------------------------------------------------

Path: /usr/lib/objrepos

bos.rte.date 7.2.3.16 COMMITTED Date Control Commands

 

Path: /etc/objrepos

bos.rte.date 7.2.3.16 COMMITTED Date Control Commands

aixserver$ oslevel -s

7200-03-03-1914

aixserver$ LANG=C TZ=UTC /opt/freeware/bin/date --date='12:00 July 29, 2019 20 years'

Fri Jul 29 12:00:00 UTC 2039

aixserver$

 

There are less than 20 years until 2038. Does AIX 7.2 TL3 SP3 have Year-2038 problems?