[Omaha.pm] Strftime between Linux/Unix and Windows differences.

[Dan Linder <dan@linder.org>]

Ran into an interesting gotcha between Perl on Linux and Perl on Windows.  See this example code:
$ cat -n ./d0039.pl
     1  #!perl
     2  use strict;
     3  use POSIX;
     4  my $epoc_sec = 1296482400;

     5  printf ("%s\n", strftime("%A, %B %e %Y at %l:%M%p", localtime($epoc_sec)));
     6  my $TT=localtime($epoc_sec);
     7  print qq{$TT \n};

On my Linux system:
$ perl ./d0039.pl
Monday, January 31 2011 at  8:00AM
Mon Jan 31 08:00:00 2011

But when run from my Windows box (Win 7, 64bit) using ActiveState:
C:\temp>perl d0039.pl
%A, %B %e %Y at %l:%M%p
Mon Jan 31 08:00:00 2011

After a bit of Googling, I found this section from the POSIX documentation:

http://perldoc.perl.org/POSIX.html

If you want your code to be portable, your format (fmt ) argument should use only the conversion specifiers defined by the ANSI C standard (C89, to play safe). These are aAbBcdHIjmMpSUwWxXyYZ% . But even then, the results of some of the conversion specifiers are non-portable. For example, the specifiers aAbBcpZchange according to the locale settings of the user, and both how to set locales (the locale names) and what output to expect are non-standard. The specifier c changes according to the timezone settings of the user and the timezone computation rules of the operating system. The Z specifier is notoriously unportable since the names of timezones are non-standard. Sticking to the numeric specifiers is the safest route.

What I don't get is why ALL of my formatting code entries don't seem to be accepted in the strftime() call...

DanL
--
***************** ************* *********** ******* ***** *** **
"Quis custodiet ipsos custodes?"
    (Who can watch the watchmen?)
    -- from the Satires of Juvenal
"I do not fear computers, I fear the lack of them."
    -- Isaac Asimov (Author)
** *** ***** ******* *********** ************* *****************