On 19/11/18 10:13 am, Ed Greshko wrote:
On 11/19/18 5:08 AM, Stephen Morris wrote:
From recollection, which may not be completely accurate, the Asrock motherboard that I
have now is the first motherboard I've had where the bios has not offered a setting to
set the system clock to GMT/Local, and I have always set the system clock to local
because Windows, which I tri-boot with, used to have issues with the system clock being
GMT. Having said this, on this motherboard there isn't any option to change it, the
front screen is showing local time and that time is correct for daylight savings time,
even though the machine wasn't switched on when daylight savings time kicked in.
I also seem to remember that there used to be an option in KDE->System Settings to
configure whether or not the system clock was running local or GMT time, which I can't
find now. The only setting I can find is to set the timezone and to set the date and
time automatically. From memory there used to also be an option in KDE->System Setttings
to have the clock maintained by a Network Time Clock where you could also specify the
URL to connect to, which I used to have set to an Oceania location,
but I can't find that anymore either.
Think about it for a moment. Does it make any sense for a motherboard to have knowledge
of time zones?
The same motherboard is used all over the world and unless you update the BIOS they would
remain static in their knowledge to time zones.
I'm not saying the motherboard bios has knowledge of timezones, what I
am saying is that other motherboards I've had have provided the facility
when setting the time in the bios to specify whether the time being
input is local time or GMT time.
I've pointed out where time zone information is kept. Those files are provided by the
tzdata package. Here is the start of the "changelog" for that package.
* Mon Nov 12 2018 Patsy Griffin Franklin <pfrankli@xxxxxxxxxx> - 2018g-1
- Rebase to tzdata-2018g
Includes changes for tzdata-2018f.
- Volgograd will change from UTC+03 to UTC+04 on 2018-10-28 at 02:00.
- Fiji will end DST on 2019-01-13 instead of the 2019-01-20 as
previously predicted.
- Most of Chile will end DST on the first Saturday in April at 24:00
and restart DST on the first Saturday in September at 24:00.
- Morocco will change from UTC+00/+01 to permanent +01 effective 2018-10-27.
* Sat Jul 14 2018 Fedora Release Engineering <releng@xxxxxxxxxxxxxxxxx> - 2018e-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Wed May 16 2018 Patsy Franklin <pfrankli@xxxxxxxxxx> - 2018e-1
- Rebase to tzdata-2018e
- North Korea changed from UTC+8:30 to UTC+9 on May 5, 2018.
- In this update, the upstream project now defaults to using
the "vanguard" data implementation which includes negative DST offsets.
Given that the front screen of the bios is displaying the time as local
time, presumably that means that the time settings in the bios are local
time and the motherboard bios doesn't provide any means to input the
time as GMT, hence the bios is not set to GMT. Thinking about the data
as displayed by journalctl at boot time, the time stamp on the messages
of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS assumed
the system clock was GMT and added the local zone offset to the time.
Given the fact that my /etc/adjtime has local as the last line, and from
my recollection I have not explicitly run the indicated commands that
would set that, why is the OS not honouring that specification right
from boot commencement?
With the time zone data coming from the tzdata package, are you saying
that each year when the local governments change when daylight saving
starts and ends, that the tzdata package is updated to reflect that?
One of the things that might be causing me confusion around this is my
belief that the hardware/system clock is the bios time data, is that not
correct? If that is correct, are people saying that if I issue the
timedatectl command to specify that the RTC is not local, that it will
adjust the bios time data to the GMT time that is relevant for the local
timezone?
regards,
Steve
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
