On 21/11/18 10:02 am, Rick Stevens wrote:
On 11/20/18 2:09 PM, Ed Greshko wrote:
> On 11/21/18 5:07 AM, Stephen Morris wrote:
>>
>> 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.
> Let me try this one last time. And it will be one last time. I can tell you how to
set
> your system up to get consistent log entries. It will be your choice to do it or
not.
>
> You have already said that the motherboard has no concept of time zones. That is
totally
> irrelevant. YOU know what time it is and YOU know what time zone you are in!
>
> I look at my mobile phone and see it is 05:55 on November 21. I know I am in GMT+8.
So,
> GMT time is now 21:55 on November 20. So, I go to my BIOS screen and enter 21:55 as
the
> time and November 20 as the date. The motherboard clock is NOW set to GMT! It
matter not
> one lick if the MB has an idea of any time zone!
>
> Step one Done.
>
>> 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?
> Set that last line to UTC. You have now told the O/S that the HW clock is set to
> UTC/GMT. So now the O/S knows what you know.
>
> Step two Done.
>
> Make sure the the link /etc/localtime points to a correct time zone for where your
system
> is physically located.
>
> [egreshko@meimei etc]$ ll /etc/localtime
> lrwxrwxrwx. 1 root root 33 Dec 21 2017 /etc/localtime ->
../usr/share/zoneinfo/Asia/Taipei
>
> for ME.
>
> (you can use timedatectl to show/set)
>
> Step three Done.
>
> Reboot
>
> Done.
>
> You will now get correct and consistent date/time stamps in your logs going forwad.
> Previous timestamps won't be fixed. Don't want to do that. Well, you'll
be in the same
> situation you are now and that will be that.
>
>
>> 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?
> Look at the changelog for the package as I showed you.
>
> rpm -q --changelog tzdata
>
> and you will see the dates it was updated and why it was updated. The answer to
your
> question is obvious.
And to make it clear, Linux expects the SYSTEM clock to be in UTC,
Windows expects it to be in local time. The SYSTEM clock is set to the
BIOS clock at boot time for both OSes. There is really no (clean) way to
make these two disparate things live together. There is a way to bugger
Windows to use a UTC clock via a registry entry, but it's a kludge.
Choose which one (Windows or Linux) is your primary OS, and set your
BIOS clock accordingly (localtime for Windows, UTC for Linux).
At the moment my main OS is Windows as I spend a fair amount of time
playing online games that can't be played under Linux, so I mainly only
boot to Linux for email processing, until such time as I decide to forgo
the gaming environment and get back into serious development work. I
haven't investigated recently the ability of VM's to provide the
necessary hardware graphics quality for gaming, but the last time I
looked at this possibility the graphics capabilities weren't up to scratch.
Given that /etc/localtime seems to be a symbolic link to
/usr/share/zoneinfo, for the same reasons that /etc may not be mounted
/usr may also not be mounted, so how does the boot system know what
offset to add to the bios time to reach local time?
Linux will handle a localtime BIOS clock better. If your BIOS clock is
in local time (as Windows wants) and you boot Linux, the log entries
will have the incorrect time until chronyd drags the SYSTEM clock into
sync with UTC. The log entries will be correct from that point onwards.
So, use journalctl to look for log entries for chronyd:
journalctl -b -u chronyd
And look for the lines that indicate the clock was reset:
<datestamp> <hostname> chronyd<[pid]>: System clock was
stepped by <some-number> seconds
I've issued the command above and the last message displayed says that
the 'System clock TAI was stepped by 37 seconds', the first two messages
displayed, both with the same timestamp were 'Starting NTP client
server' and 'cronyd version 3.14 starting'. The thing that was
interesting about all the messages displayed by the journalctl command
was that the timestamp on all the messages was local time, which I
assume means that the system clock was running in local time before
cronyd was started?
regards,
Steve
>
> Log entries before that assume your local time is UTC, will be displayed
> adjusted for your local timezone and will be off by whatever your
> timezone is. Entries after that will be based on the real UTC, displayed
> as your local timezone and will be correct. That's just the way it is
> (unfortunately).
> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
> - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
> - -
> - Change is inevitable, except from a vending machine. -
> ----------------------------------------------------------------------
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org