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?

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;
[download]

and

print time;
[download]

Am I missing something?

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

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

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\

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

#!/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 }
[download]

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.