in reply to Re: Question regarding Time::Piece and timezones
in thread Question regarding Time::Piece and timezones

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

Replies are listed 'Best First'.
Re^3: Question regarding Time::Piece and timezones
by Marshall (Canon) on Jan 14, 2021 at 12:26 UTC
    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]
        From https://www.apparent-wind.com/gmt-explained.html
        Prior to 1925, astronomers reckoned mean solar time from noon so that when the mean sun was on the meridian, it was actually 00:00 GMT. This practice arose so that astronomers wouldn't have a change in date during a night's observing. Some in the astronomical community still use the pre-1925 definition of GMT in the analysis of old data although it is recommended that the term Greenwich Mean Astronomical Time now be used to refer to time reckoned from noon.
[reply]

In Section Seekers of Perl Wisdom