Bug 1792652

Summary:	boots to GMT/Zulu time until network on
Product:	[Fedora] Fedora	Reporter:	Nick Levinson <Nick_Levinson>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED CANTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	31	CC:	lnykryn, msekleta, ssahani, s, systemd-maint, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-03-31 14:17:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nick Levinson 2020-01-18 21:17:36 UTC

Description of problem: When going from no power to power and booting, even though BIOS was set to local time, the OS changes the time to GMT/Zulu until sometime after computer is networked and retrieves the time from the Internet.

Version-Release number of selected component (if applicable): Unknown to me.

How reproducible: Always.

Steps to Reproduce:
0. Whether you have the problem depends on your computer model and maybe on your desktop environment. I had the problem on a Dell Latitude E6400 laptop and Gnome. Also, don't be in the Greenwich Mean Time (GMT) zone.
1. Have networking off and disconnected.
2. Deprive the computer of AC and DC. In other words, disconnect the power cable and remove the battery for at least a few seconds.
3. Reconnect power, either AC or DC.
4. Boot.
5. Depending on your computer model, you may be prompted to set your coomputer's current date and time.
5a. If so, do so, so it conforms to your local date and time.
5b. If your computer does not prompt you for the date and time, I don't know if this bug report applies to you.
6. Finish booting.
7. Do not reconnect to a network.
8. Check the desktop's top panel for the current time. Confirm in Settings > Details > Date & Time.

Actual results: The date and time (usually only the time differs) will conform to GMT. This won't change until networking is on, and even then usually not immediately.

Expected results: Conformance to BIOS settings for date and time even if offline since booting.

Additional info: Files saved during this period will be time-stamped per GMT rather than per the BIOS, more or less unexpectedly as far as the user is concerned.

Comment 1 Zbigniew Jędrzejewski-Szmek 2020-03-31 14:17:17 UTC

It sounds like your RTC battery died. I think the best solution would be to simply exchange
the battery (it can be removed and replaced w/o any special tools usually).

On the software side, it sounds like you machine sets the RTC clock to local time. This is a
generally broken concept that cannot be made to work. As a work-around, you can tell the
system that RTC is using localtime with 'timedatectl set-local-rtc 1'. If you have other
OSes installed on the same machine, this should work OK.

Comment 2 Nick Levinson 2020-04-03 00:43:35 UTC

You're likely right that the CMOS battery should be replaced, but I use it daily but cold-boot only every few weeks or couple of months or so and the BIOS password still works. Since the error is not in the time displayed by BIOS after I set it but is in what is displayed by the OS/DE even later, wrong by just a few time zones, I doubt that's a battery problem. With info timedatectl I see timedatectl status --all has RTC=UTC so I think the easiest way out for me is to live with the error and let online snchronization take care of it albeit ith a bit of a delay.

It has only one OS, with a choice of kernels, unless I boot from a live CD.

I'm leaving the bug status as is.

Thanks. I didn't know about timedatectl.

Comment 3 Zbigniew Jędrzejewski-Szmek 2020-04-03 12:16:27 UTC

>  timedatectl status --all has RTC=UTC 

Yes, and 'timedatectl set-local-rtc 1' would switch it to "local" mode.

OK, I think that there's no bug here, in the sense that there's a known failure
stemming from BIOS and Microsoft Windows insisting to use RTC in local mode that
we can't do much about.

Comment 4 Nick Levinson 2020-05-27 19:05:19 UTC

That's puzzling, partly since I was quite thorough in erasing everything from the HDD (running DBAN) and see no trace of Windows. But if the Dell laptop's BIOS was designed to support Windows in a way that Linux can't access and correct for, that would be interesting; or maybe timedatectl is intended to correct for it.

info timedatectl describes a limitation on set-local-rtc 1 that makes it more trouble than it's worth unless I maintain an offline note to myself to manually update between daylight and standard and woe to frequent travellers crossing zones.

Yesterday, I was online with the correct local time (within a minute or two) but when I lost my Internet connection it reverted to GMT until I got a network connection again. Also, both times yesterday, auto-coordinating the time to local time took longer than usual. So maybe you're right that it's likely a BIOS battery problem.

Comment 5 Nick Levinson 2020-07-22 18:05:24 UTC

The coin cell battery module was about 11 years old, so it was about time to replace it. I replaced the coin cell battery (CR2032) module with a new OEM one, and I haven't seen a time zone error since. I don't even have to enter the current date and time anymore. When I swap the main battery without AC power, I usually complete the swap within just a few seconds, and maybe if I took longer Setup would forget the date, time, and zone. I have not tested a longer interruption between swaps. Also, since replacing the module, I have not seen a problem after going offline about the desktop showing non-local GMT. So, this seems to confirm the diagnosis in comment 1, not quite that the battery died but that it was dying. Thank you.

On the replacement procedure: http://brittlebit.org/hardware/replacing-the-coin-cell-battery-in-the-dell-latitude-e6400.html