timezone not being correctly determined on raspbian

[bkerin]

I set the time zone with the modern mantra:

# timedatectl set-timezone US/Alaska

Then /etc/localtime seems right:

# file /etc/localtime
/etc/localtime: symbolic link to ../usr/share/zoneinfo/US/Alaska
# file -L /etc/localtime
/etc/localtime: timezone data (fat), version 2, 9 gmt time flags, 9 std time flags, no leap seconds, 144 transition times, 9 local time types, 40 abbreviation chars

and date gets it right:

# date
Wed  3 Apr 12:49:05 AKDT 2024

But DateTime::TimeZone still doesn't seem to:

# perl -MDateTime::TimeZone -e 'print DateTime::TimeZone->new( name => "local" )."\n"'
DateTime::TimeZone::Europe::London=HASH(0x55bd597258)

I notice that /etc/timezone still seems wrong:

# cat /etc/timezone
Europe/London

So it seems that either the description at https://metacpan.org/pod/DateTime::TimeZone::Local::Unix is not right (or at least misleading) about the order in which things are tried, or else the way that raspbian is normally doing things these days somehow doesn't get picked up by the /etc/localtime handling in DateTime::TimeZone.

[bkerin]

I tried replacing the contents of /etc/timezone with US/Alaska and this seems to trigger correct handling (and not just a copy of the value in there):

# echo 'US/Alaska' >/etc/timezone
# perl -MDateTime::TimeZone -e 'print DateTime::TimeZone->new( name => "local" )."\n"'
DateTime::TimeZone::America::Anchorage=HASH(0x5571882578)

[autarch]

I'm not sure what happened. I'm quite sure the behavior as documented is the order in which it checks for things. One (unlikely) possibility is that the /etc/localtime file wasn't readable by the Perl process you ran. That would cause the /etc/localtime checks to be skipped.

The only way to really figure out what happened is to put a bunch of debugging statements in the code and see what happens when you run it on the machine in question.

[mhkrebs]

Looking at the source for Local/Unix.pm, it looks like it checks /etc/timezone before /etc/localtime (source code). This confused me since the docs do imply the opposite. And I ran into the same issue as the OP.

Things like the date command seem to look at /etc/localtime first. And various Stack Overflow web sites imply that /etc/localtime is the standard way to figure out the local time zone (e.g. this answer).

Is it too late to change DateTime to get the local time zone with FromEtcLocaltime() before FromEtcTimezone()?

[autarch]

The change to the behavior was made in 2014, so at this point I think the best thing to do is fix the docs, not change the order it checks things in.

[autarch]

BTW, the reason the order was changed back in 2014 is because the /etc/timezone check is very quick, whereas the /etc/localtime check can be much slower. That's because the latter may end up looking through all the installed IANA tz database files.

[bkerin]

It might be good to also explicitly document that at least some recent distros don't do a good job of updating /etc/timezone at all. The issue of slow timezone checks is rightly documented, and this one seems at least as significant.

[autarch]

It might be good to also explicitly document that at least some recent distros don't do a good job of updating /etc/timezone at all. The issue of slow timezone checks is rightly documented, and this one seems at least as significant.

Good idea. I just pushed a doc change that does this.

[bkerin]

Nice, resolved as far as I'm concerned.