The scalar value of localtime is explicitly not locale dependent. It is a fixed format, see ctime(3) | [reply] |
perlfunc also mentions this
This scalar value is not locale dependent but is a Perl builtin. ...
To get somewhat similar but locale dependent date strings, set up your locale environment variables appropriately ... use POSIX qw(strftime);
| [reply] [d/l] |
That's a curious way of phrasing it. It seems to suggest that anything that's a Perl builtin isn't locale dependent. But grepping through the perlfunc manual page does reveal builtins that have a locale dependency: lc, lcfirst, (s)printf, sort, uc, ucfirst. And then there are regular expressions.
| [reply] |
I stand corrected.
I however probably still wouldn't rely on it as there are probably way too many other functions that /do/ depend on the locale, or suddenly behave different if POSIX comes into play (or when it explicitely does not), or when modules happen to be in place that overrule this default.
Enjoy, Have FUN! H.Merijn
| [reply] |
| [reply] [d/l] |
Not to be arguing, but what /would/ it be called then, when using the script in a multi-langual environment, or when you do not know what the locale will be at execution time?
I really like the simplicity of the approach. I always want to answer the stupid question "How do I print yesterday in perl?" with 'print "yesterday"', which is a perfect answer, but obviously not what the question was about. I've hit this locale problem way too often to not care, and if you'd use a regex match, the easy way out is to use { local $ENV{LC_TIME} = "en_US"; ... }.
Enjoy, Have FUN! H.Merijn
| [reply] [d/l] |
sub firstDayOfWeek {
my $now = time;
my @now = localtime $now;
return $now - ( $now[ 6 ] * 2 - 1 ) * 43200;
}
| [reply] [d/l] |