in reply to Question regarding Time::Piece and timezones

Edited.. 
use strict;
use warnings;
use Time::Piece;

my $t = localtime();

my $pattern = "%a, %d %b %Y %T %Z";

my $str = $t->strftime ($pattern);
print "Time is:\n", $str, "\n";

__END__
example:

Time is:
Wed, 13 Jan 2021 23:08:46 Pacific Standard Time

[download]

Replies are listed 'Best First'.
Re^2: Question regarding Time::Piece and timezones
by GrandFather (Saint) on Jan 14, 2021 at 06:53 UTC 
    my $t = localtime;

    [download]

    There are more moving parts than the minimum required to show the problem, which is surprising in such a short example script! The issue could as well have been illustrated using:

    use strict;
use warnings;
use Time::Piece;

my $pattern = "%a, %d %b %Y %T %Z";
my $str = 'Wed, 13 Jan 2021 17:22:23 CST';
my $u = Time::Piece->strptime($str, $pattern);

print "Time is:\n", $u->strftime($pattern), "\n";

    [download]

    which doesn't give the trace back, but does show the error:

    Error parsing time at d:/berrybrew/5.30.1_32/perl/lib/Time/Piece.pm li
+ne 597.

    [download]
    Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
[reply]
[d/l]
[select]
      Yes, there are many moving parts to time/date calculations!

      I personally always use gmtime(), which is close to utc time.
      There is a slight difference between gm and utc time, but not much.
      The difference is so small that I don't want to argue about it.

      I recommend using GM or UTC time for all values stored in a DB.
      Use a a conversion module like Time::Piece for translation to
      translate the DB time to a user time zone.

      My local government had a problem with the fall time change.
      This actually allowed bars to remain open for one extra hour on one day of the year.
      They fixed that "problem".
      gmtime() just marches onward- there is no "fall back".

[reply]
        There is a slight difference between gm and utc time, but not much. The difference is so small that I don't want to argue about it.

        No need to argue when there's a source to cite.

        🦛

[reply]

        Yes, and were it my preference the data would be in GMT/UTC until someone asked for it in another TZ. (And yes, I'm aware there is a slight difference in GMT v. UTC, but most people aren't aware of them until they hear about a "leap second", or the possible horror of a "negative leap second".) Unfortunately the data I am given includes time stamps from at least five different time zones, and it falls to me to compare them as part of other processing. Since Time::Piece is core and pops up periodically as a suggestion when questions arise about dates/times including TZs (such as a response to a post yesterday), I thought I should go ahead and post my question.

[reply]
        I recommend using GM or UTC time for all values stored in a DB.
        Use a a conversion module like Time::Piece for translation to
        translate the DB time to a user time zone.

        If my code is connecting to a database, I usually use that to do all the time arithmetic and conversion that I need...

[reply]
        On Linux at least, gmtime() actually returns UTC. As explained in hippo’s link, GMT in common use is often used as a synonym for UTC, but GMT has other meanings differing by a few seconds or 12 hours!.
[reply]

In Section Seekers of Perl Wisdom