Solaris 11 Sets TZ = localtime

[rodenj1]

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.

[SBECK-github]

I tried a simple test that I thought would reproduce this, but I did not get the warnings that you did. Could you send me a very simple script that you run and get the above warnings and error. Also, please send me the version of Date::Manip you are using and the version of perl you are running. To save time, could you also set an environment variable DATE_MANIP_DEBUG=1 and run that test script and include the output?

That'll help me to determine what's going on. I thought that Date::Manip would correctly handle an incorrect timezone value (i.e. ignore it and move on to another method).

[rodenj1]

Here you go! Simple script…

use strict; use warnings;

use Date::Manip print "Perl Version: $]\n"; print "Date::Manip Version: $Date::Manip::VERSION\n"

Here is the debug output…

./date_manip_test.pl DEBUG METHOD: main [TZ] undef DEBUG METHOD: env [zone,TZ] localtime DEBUG METHOD: file [/etc/TIMEZONE] localtime DEBUG METHOD: file [/etc/timezone] not found DEBUG METHOD: file [/etc/sysconfig/clock] not found DEBUG METHOD: file [/etc/default/init] localtime DEBUG METHOD: tzdata [] 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. DEBUG METHOD: command [/bin/date +%Z] PST DEBUG METHOD: main [TZ] undef DEBUG METHOD: env [zone,TZ] localtime DEBUG METHOD: file [/etc/TIMEZONE] localtime DEBUG METHOD: file [/etc/timezone] not found DEBUG METHOD: file [/etc/sysconfig/clock] not found DEBUG METHOD: file [/etc/default/init] localtime DEBUG METHOD: tzdata [] 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. DEBUG METHOD: command [/bin/date +%Z] PST Perl Version: 5.022002 Date::Manip Version: 6.56

I hope this helps! And that thank you for taking a look into it! :D

John

On Jan 26, 2017, at 4:37 AM, Sullivan Beck notifications@github.com wrote:

I tried a simple test that I thought would reproduce this, but I did not get the warnings that you did. Could you send me a very simple script that you run and get the above warnings and error. Also, please send me the version of Date::Manip you are using and the version of perl you are running. To save time, could you also set an environment variable DATE_MANIP_DEBUG=1 and run that test script and include the output?

That'll help me to determine what's going on. I thought that Date::Manip would correctly handle an incorrect timezone value (i.e. ignore it and move on to another method).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SBECK-github/Date-Manip/issues/8#issuecomment-275378864, or mute the thread https://github.com/notifications/unsubscribe-auth/AH7heowmFJ6gs6gmH_5Ll2Ta8-FNgu3fks5rWJOmgaJpZM4Ltyz5.

[SBECK-github]

Thanks. That really helps.

So, you've found a bug and a problem... but neither are with the localtime value. Date::Manip is behaving as I remembered by just going through a list of methods and when it finds something it doesn't understand, it goes on to the next one. It finds 'localtime' in several of the methods, but since that's not a known timezone, it just goes on and tries the next method. So you can safely ignore the TZ=localtime issue.

The bug is that one of the methods (tzdata) failed to trap an undef and it resulted in the warnings, and worse, it passed undef on to another function which gave the error message you see. The tzdata method didn't give an undef on my system, so I've got to see what would cause that and fix it. Now despite this, Date::Manip just went on to the next method, and eventually found that your timezone was specified as PST, and that's valid, so it stopped at that point.

You can verify that by changing the last line in your script to be:

print "Date::Manip Version ",DateManipVersion(1),"\n";

which will show you the timezone determined.

The other problem you've uncovered is that for some reason, it's running through the list of methods twice... so I'm initializing the timezone twice, when I should only do it once. It's not a horrible problem... but I don't like it, so I'll track it down and correct that as well.

Go ahead and verify that the timezone is correctly determined (by changing your simple script). I'll let you know when I have a fixed version you can try.

[SBECK-github]

The bug portion is fixed and will be in the next release. You can download a copy with the fix from

http://sullybeck.com/Date-Manip-6.58.tar.gz

The fact that it runs through the list of methods twice turned out to be necessary. When you use the non-object oriented interface, it creates two permanent objects (one in your local timezone and one in UTC), and the local timezone is determined for each (though it is discarded for the latter object), so that's okay. If you use the OO interface, then it only runs through the list once.

[rodenj1]

Awesome and thank you!

I did verify that it was setting the right TZ eventually!

John

On Jan 26, 2017, at 1:08 PM, Sullivan Beck notifications@github.com wrote:

The bug portion is fixed and will be in the next release. You can download a copy with the fix from

http://sullybeck.com/Date-Manip-6.58.tar.gz http://sullybeck.com/Date-Manip-6.58.tar.gz The fact that it runs through the list of methods twice turned out to be necessary. When you use the non-object oriented interface, it creates two permanent objects (one in your local timezone and one in UTC), and the local timezone is determined for each (though it is discarded for the latter object), so that's okay. If you use the OO interface, then it only runs through the list once.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SBECK-github/Date-Manip/issues/8#issuecomment-275514283, or mute the thread https://github.com/notifications/unsubscribe-auth/AH7hekMHx7iX3Syu2bYsGWMs2rch9ioJks5rWQtkgaJpZM4Ltyz5.