On 11/20/18 1:07 PM, Stephen Morris wrote: > 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? What happens is the SYSTEM clock (which is what the OS uses for internal stuff and is expected to be in UTC) is set to the BIOS clock at boot. AFAIK, the variable in /etc/adjtime is not looked at as /etc may not have been mounted yet (don't know this for sure, but it seems to work like that). >From then on, the BIOS clock is ignored as far as the OS is concerned. NTP clients (chronyd) keep the SYSTEM clock synchronized to UTC. You have the option of resetting the BIOS clock to the SYSTEM clock via the hwclock command, and setting the LOCAL or UTC flag on that command will set the BIOS clock appropriately as the hwclock command has access to /etc/adjtime at that point. However, until chronyd gets the SYSTEM clock synchronized to UTC, your log entries will reflect the (erroneous) BIOS clock time. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - The trouble with troubleshooting is that trouble sometimes - - shoots back. - ---------------------------------------------------------------------- _______________________________________________ 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
