Mailing List Archive

Mark Knecht posted on Wed, 06 Jan 2016 07:38:15 -0800 as excerpted:

> The solution to this is eluding me. What changes, other than changing
> /etc/timezone, are required to get a Gentoo machine to recognize that it
> has moved physically and is living in a new timezone?
>
> I've just moved from Silicon Valley to Tucson, AZ. The machine came up
> fine other than time being off by 1 hour which I expected. I changed
> /etc/timezone from America/Los_Angeles to America/Phoenix and rebooted
> and yet time is still showing California time.
>
> The system clock is UTC. [snipped]

Welcome to AZ. I'm in Phoenix. Talking about time, the really nice
thing about AZ is that it doesn't do daylight savings time, so you don't
have to worry about time jumping around twice a year. =:^)

I first read your message this AM, before work, but while I remembered
that there was another file to configure, I forgot what it was, and
didn't have time to look it up, so it had to wait until tonite.

So I just looked it up in the handbook, and thus can point you right at
it. =:^)

https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Timezone

You did the first part of it, setting /etc/timezone, but didn't do the
second part, setting /etc/localtime, which is used by glibc to know your
timezone. You can either do it using the command in the handbook:

emerge --config sys-libs/timezone-data

... or you can do it manually by copying the appropriate timezone file
from /usr/share/zoneinfo/ to /etc/localtime, for AZ:

cp /usr/share/zoneinfo/America/Phoenix /etc/localtime

(Every time you update the timezone-data package, its pkg_postinst() runs
pkg_config(), which is what that emerge call does semi-manually, above.
pkg_config in turn copies the appropriate file to /etc/localtime based
on /etc/timezone, thus updating /etc/localtime with the timezone file
from the freshly installed timezone-data package. The cp alternative
simply does that same cp manually. You can of course take a look at the
timezone-data ebuild itself to see exactly how it does it, if you like.
It does get slightly fancier with its logic, setting factory if the
timezone is invalid, not touching the localtime file if it's a symlink
instead of an actual file, etc, but basically, just does the above under
normal circumstances. =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Wed, Jan 6, 2016 at 8:30 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>
> Mark Knecht posted on Wed, 06 Jan 2016 07:38:15 -0800 as excerpted:
>
> > The solution to this is eluding me. What changes, other than changing
> > /etc/timezone, are required to get a Gentoo machine to recognize that it
> > has moved physically and is living in a new timezone?
> >
> > I've just moved from Silicon Valley to Tucson, AZ. The machine came up
> > fine other than time being off by 1 hour which I expected. I changed
> > /etc/timezone from America/Los_Angeles to America/Phoenix and rebooted
> > and yet time is still showing California time.
> >
> > The system clock is UTC. [snipped]
>
> Welcome to AZ. I'm in Phoenix. Talking about time, the really nice
> thing about AZ is that it doesn't do daylight savings time, so you don't
> have to worry about time jumping around twice a year. =:^)
>
> I first read your message this AM, before work, but while I remembered
> that there was another file to configure, I forgot what it was, and
> didn't have time to look it up, so it had to wait until tonite.
>
> So I just looked it up in the handbook, and thus can point you right at
> it. =:^)
>
> https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Timezone
>
> You did the first part of it, setting /etc/timezone, but didn't do the
> second part, setting /etc/localtime, which is used by glibc to know your
> timezone. You can either do it using the command in the handbook:
>
> emerge --config sys-libs/timezone-data
>
> ... or you can do it manually by copying the appropriate timezone file
> from /usr/share/zoneinfo/ to /etc/localtime, for AZ:
>
> cp /usr/share/zoneinfo/America/Phoenix /etc/localtime
<SNIP>

Thanks Duncan. I looked at that file (cat /etc/timezone) for a moment
this morning - the name is so obvious - but it was a binary and then
for some reason I never followed up in Google. My bad. All fixed now.

If you find yourself in Tucson let me know and I'll buy you a beer or
two (or whatever you drink) for all the help over the years.

Gotta say I'm digging all the jazz on NPR here at night. I was in the
Bay Area for the last nearly 40 years and KQED up there is a power
house station but nighttime radio was more or less a repeat of what's
on during the day. The Tucson station is more varied.

Cheers,
Mark

Duncan wrote:
> Mark Knecht posted on Wed, 06 Jan 2016 07:38:15 -0800 as excerpted:
>
>> The solution to this is eluding me. What changes, other than changing
>> /etc/timezone, are required to get a Gentoo machine to recognize that it
>> has moved physically and is living in a new timezone?
>>
>> I've just moved from Silicon Valley to Tucson, AZ. The machine came up
>> fine other than time being off by 1 hour which I expected. I changed
>> /etc/timezone from America/Los_Angeles to America/Phoenix and rebooted
>> and yet time is still showing California time.
>>
>> The system clock is UTC. [snipped]
> Welcome to AZ. I'm in Phoenix. Talking about time, the really nice
> thing about AZ is that it doesn't do daylight savings time, so you don't
> have to worry about time jumping around twice a year. =:^)
>
> I first read your message this AM, before work, but while I remembered
> that there was another file to configure, I forgot what it was, and
> didn't have time to look it up, so it had to wait until tonite.
>
> So I just looked it up in the handbook, and thus can point you right at
> it. =:^)
>
> https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Timezone
>
> You did the first part of it, setting /etc/timezone, but didn't do the
> second part, setting /etc/localtime, which is used by glibc to know your
> timezone. You can either do it using the command in the handbook:
>
> emerge --config sys-libs/timezone-data
>
> ... or you can do it manually by copying the appropriate timezone file
> from /usr/share/zoneinfo/ to /etc/localtime, for AZ:
>
> cp /usr/share/zoneinfo/America/Phoenix /etc/localtime
>
> (Every time you update the timezone-data package, its pkg_postinst() runs
> pkg_config(), which is what that emerge call does semi-manually, above.
> pkg_config in turn copies the appropriate file to /etc/localtime based
> on /etc/timezone, thus updating /etc/localtime with the timezone file
> from the freshly installed timezone-data package. The cp alternative
> simply does that same cp manually. You can of course take a look at the
> timezone-data ebuild itself to see exactly how it does it, if you like.
> It does get slightly fancier with its logic, setting factory if the
> timezone is invalid, not touching the localtime file if it's a symlink
> instead of an actual file, etc, but basically, just does the above under
> normal circumstances. =:^)
>


It's been a long time since I did this but isn't that supposed to be a
link instead of a copy? I'm pretty sure it was a link long ago but they
may have changed it.

Just to be sure.

Dale

:-) :-)

Dale posted on Thu, 07 Jan 2016 00:55:31 -0600 as excerpted:

>> You did the first part of it, setting /etc/timezone, but didn't do the
>> second part, setting /etc/localtime, which is used by glibc to know
>> your timezone. You can either do it using the command in the handbook:
>>
>> emerge --config sys-libs/timezone-data
>>
>> ... or you can do it manually by copying the appropriate timezone file
>> from /usr/share/zoneinfo/ to /etc/localtime, for AZ:
>>
>> cp /usr/share/zoneinfo/America/Phoenix /etc/localtime
>>
>> (Every time you update the timezone-data package, its pkg_postinst()
>> runs pkg_config(), which is what that emerge call does semi-manually,
>> above. pkg_config in turn copies the appropriate file to /etc/localtime
>> based on /etc/timezone, thus updating /etc/localtime with the timezone
>> file from the freshly installed timezone-data package. The cp
>> alternative simply does that same cp manually. You can of course take
>> a look at the timezone-data ebuild itself to see exactly how it does
>> it, if you like. It does get slightly fancier with its logic, setting
>> factory if the timezone is invalid, not touching the localtime file if
>> it's a symlink instead of an actual file, etc, but basically, just does
>> the above under normal circumstances. =:^)
>>
> It's been a long time since I did this but isn't that supposed to be a
> link instead of a copy? I'm pretty sure it was a link long ago but they
> may have changed it.

Take a look at the code in timezone-data's pkg_config. It's commented
and easy enough to follow for those who are comfortable with bash, as
gentooers certainly /should/ be. =:^)

That function (which is run as part of the handbook's installation
instructions) checks for a symlink and specifically assumes the user
knows what they are doing if it's a symlink, but defaults to a cp based
on the timezone set in /etc/timezone, unless /etc/localtime is a symlink.

So a symlink should work if a user creates it manually, but the file is
normally copied.

I'd guess the reason is because gentoo still tries to allow for a
separate /usr, which would of course mean a dead symlink in early (pre-
mount but for /) boot, which is when openrc tries to set the time, in
ordered to properly check config file modification times to see if it
needs to recache service ordering. Openrc then falls back to I think
UTC, which will likely trigger a time-skew complaint when the cache files
appear to be from the future (for folks in UTC-minus timezones, anyway).

For people with /usr/share/zoneinfo/* on / (or who use an initr* that
mounts /usr), the symlink should work fine, and is arguably easier to
check, since you can just check where the symlink points instead of
having to diff against the zoneinfo timezone file you /think/ it should
be to be sure it's correct (which is what I did here, checking my own
system to be sure it was set that way, before posting).

But while my /usr is on / (and I'm on systemd so that particular issue
wouldn't apply, but others might), I've left localtime as an actual file,
because that's the default solution, thus most widely tested and least
likely to cause additional bugs. I don't hesitate to diverge from the
defaults where I have some reason to prefer doing it differently, and
there are indeed lots of places I do just that and I sometimes see bugs
nobody else seems to see as a result, but here, I don't really care, so
I've picked my additional bug risks and don't find the need to make this
one of them. =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Duncan wrote:
> Dale posted on Thu, 07 Jan 2016 00:55:31 -0600 as excerpted:
>
>>> You did the first part of it, setting /etc/timezone, but didn't do the
>>> second part, setting /etc/localtime, which is used by glibc to know
>>> your timezone. You can either do it using the command in the handbook:
>>>
>>> emerge --config sys-libs/timezone-data
>>>
>>> ... or you can do it manually by copying the appropriate timezone file
>>> from /usr/share/zoneinfo/ to /etc/localtime, for AZ:
>>>
>>> cp /usr/share/zoneinfo/America/Phoenix /etc/localtime
>>>
>>> (Every time you update the timezone-data package, its pkg_postinst()
>>> runs pkg_config(), which is what that emerge call does semi-manually,
>>> above. pkg_config in turn copies the appropriate file to /etc/localtime
>>> based on /etc/timezone, thus updating /etc/localtime with the timezone
>>> file from the freshly installed timezone-data package. The cp
>>> alternative simply does that same cp manually. You can of course take
>>> a look at the timezone-data ebuild itself to see exactly how it does
>>> it, if you like. It does get slightly fancier with its logic, setting
>>> factory if the timezone is invalid, not touching the localtime file if
>>> it's a symlink instead of an actual file, etc, but basically, just does
>>> the above under normal circumstances. =:^)
>>>
>> It's been a long time since I did this but isn't that supposed to be a
>> link instead of a copy? I'm pretty sure it was a link long ago but they
>> may have changed it.
> Take a look at the code in timezone-data's pkg_config. It's commented
> and easy enough to follow for those who are comfortable with bash, as
> gentooers certainly /should/ be. =:^)
>
> That function (which is run as part of the handbook's installation
> instructions) checks for a symlink and specifically assumes the user
> knows what they are doing if it's a symlink, but defaults to a cp based
> on the timezone set in /etc/timezone, unless /etc/localtime is a symlink.
>
> So a symlink should work if a user creates it manually, but the file is
> normally copied.
>
> I'd guess the reason is because gentoo still tries to allow for a
> separate /usr, which would of course mean a dead symlink in early (pre-
> mount but for /) boot, which is when openrc tries to set the time, in
> ordered to properly check config file modification times to see if it
> needs to recache service ordering. Openrc then falls back to I think
> UTC, which will likely trigger a time-skew complaint when the cache files
> appear to be from the future (for folks in UTC-minus timezones, anyway).
>
> For people with /usr/share/zoneinfo/* on / (or who use an initr* that
> mounts /usr), the symlink should work fine, and is arguably easier to
> check, since you can just check where the symlink points instead of
> having to diff against the zoneinfo timezone file you /think/ it should
> be to be sure it's correct (which is what I did here, checking my own
> system to be sure it was set that way, before posting).
>
> But while my /usr is on / (and I'm on systemd so that particular issue
> wouldn't apply, but others might), I've left localtime as an actual file,
> because that's the default solution, thus most widely tested and least
> likely to cause additional bugs. I don't hesitate to diverge from the
> defaults where I have some reason to prefer doing it differently, and
> there are indeed lots of places I do just that and I sometimes see bugs
> nobody else seems to see as a result, but here, I don't really care, so
> I've picked my additional bug risks and don't find the need to make this
> one of them. =:^)
>


I'll take your word for it because I don't do bash. I just need to
remember that it is changed now.

Dale

:-) :-)