Re^2: 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

Comment on Re^2: Question regarding Time::Piece and timezones Select or Download Code

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]
Re^4: Question regarding Time::Piece and timezones by hippo (Bishop) on Jan 14, 2021 at 13:25 UTC
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]
Re^4: Question regarding Time::Piece and timezones by atcroft (Abbot) on Jan 15, 2021 at 00:03 UTC
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]
Re^4: Question regarding Time::Piece and timezones by Bod (Parson) on Jan 14, 2021 at 23:55 UTC
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]
Re^4: Question regarding Time::Piece and timezones by jszinger (Scribe) on Jan 15, 2021 at 18:06 UTC
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]
Re^5: Question regarding Time::Piece and timezones by jszinger (Scribe) on Jan 26, 2021 at 17:14 UTC
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]
Re^6: Question regarding Time::Piece and timezones by Marshall (Canon) on Jan 30, 2021 at 02:20 UTC


There's more than one way to do things
	PerlMonks