http://qs1969.pair.com?node_id=579985

jeanluca has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks

When I develop software I normally develop it on my Linux workstation and when its finished I copy it to an operational unix system. The following code demonstrates my problem:
#! /usr/local/bin/perl -lw use strict ; use POSIX 'strftime' ; $ENV{TZ} = 'GMT' ; my $t = time() ; print strftime("%s", localtime(int $t)) ;
On my Linux machine this works fine (perl v5.8.8), it prints epoch seconds, however, on the unix machine (perl v5.8.7) it prints: %s

I get the impression that %s is somehow not supported (man strftime).
I've actually no idea how to solve this, so all suggestions would be very welcome!!

Thanks in advance
LuCa

Replies are listed 'Best First'.
Re: problem with 'strftime' on unix systems
by davorg (Chancellor) on Oct 23, 2006 at 11:06 UTC

    Looks like you're right and %s isn't supported in all strftime implementations.

    Seems a bit pointless here tho'. Your variable $t already contains the number of seconds since the epoch. Why would you want to convert it?

    --
    <http://dave.org.uk>

    "The first rule of Perl club is you do not talk about Perl club."
    -- Chip Salzenberg

      Probably to change the timezone at a guess.

      /J\

        But the epoch isn't effected by timezone. It's the number of seconds since 00:00 on 1st Jan 1970 GMT. I can't see how you'll ever get different answers from:

        print strftime '%s', localtime;

        and

        print time;

        Am I missing something?

        --
        <http://dave.org.uk>

        "The first rule of Perl club is you do not talk about Perl club."
        -- Chip Salzenberg

Re: problem with 'strftime' on unix systems
by gellyfish (Monsignor) on Oct 23, 2006 at 11:10 UTC

    You probably want to use POSIX::mktime instead.

    But yes %s is not a standard conversion specification (the glibc documentation notes which ones are extensions of the standard).

    /J\

Re: problem with 'strftime' on unix systems
by Anonymous Monk on Oct 23, 2006 at 11:03 UTC
    You don't specify what flavour of the dozens of Unices that are out there you are using, let alone which version. So, it's hard to solve the specific problem.

    However, on my Linux box, "%s" prints the number of seconds since the Epoch. Since that's what gmtime is returning, why use the long about route using strftime in the first place? Wouldn't perl -lwe 'print gmtime' to the trick?

      Wouldn't perl -lwe 'print gmtime' to the trick?

      I think you mean time, not gmtime.

      --
      <http://dave.org.uk>

      "The first rule of Perl club is you do not talk about Perl club."
      -- Chip Salzenberg

Re: problem with 'strftime' on unix systems
by jeanluca (Deacon) on Oct 23, 2006 at 12:56 UTC
    Ok, so I have accepted that strftime on sol10 and sol8 does not support %s :(
    Also, the reason why I convert epoch seconds to epoch seconds (which doesn't change anything) is because the format is defined by the user, it can be anything.
    Anyway I think I have to solve it like this (I don't have much time)
    #!/usr/bin/perl -lw use strict ; use POSIX 'strftime' ; my $fmt ; $fmt = <STDIN> ; chomp($fmt) ; my $time = time() ; if ( $fmt eq "%s") { print $time } else { print strftime $fmt, $time }
    Looks OK to me !?!

    Thnx
    LuCa

      You might to want think carefully before passing user supplied input to the format string of strftime, the POSIX passes this virtually unchanged to the system strftime where there is potential for a 'Format String Vulnerability'.

      /J\

      So, where's the user pulling '%s' from then? What if the user gives '%q'? (Not defined for strftime at all) Or '-%s-'? (Also has %s in it). Or '%k' (Which comes from the same package as '%s' comes from)? Or '%P' (A GNU extension, likely to work on Linux, but not a real Unix)?

      I think you should either say that the user gets whatever his current platform support (meaning that a given format will be the same for different applications on the same platform that use strftime), or you should write your own 'strftime' implementation (meaning that your application behaves the same on different platforms). Both solutions have different advantages when it comes to interoperatbility. But writing your own strftime implementation takes a lot more time, and is unlikely to be as fast as the one from libc. Whether or not that's an issue, I cannot judge.

Re: problem with 'strftime' on unix systems
by jeanluca (Deacon) on Oct 23, 2006 at 16:05 UTC
    as suggested by gellyfish and others I will indeed define which characters can be used to format the date/time (and of course check the input).

    thnk a lot
    LuCa