Bug 970542 - Wrong time display on the login screen
Wrong time display on the login screen
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: lxde-common (Show other bugs)
19
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Christoph Wickert
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-04 05:48 EDT by Jean-Pierre André
Modified: 2015-02-17 10:26 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 10:26:56 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jean-Pierre André 2013-06-04 05:48:52 EDT
Description of problem:

With an LXDE DE, the time displayed on the login screen is wrong, when the hardware clock is configured for local time

Version-Release number of selected component (if applicable):

Fedora 19 beta

How reproducible:

Always

Steps to Reproduce:
1. Configure the hardware clock for local time
2. Reboot
3. Examine the time displayed upper right on the login screen

Actual results:

The time is wrong. It is computed assuming the hardware clock is UTC
(At 08:00 UTC, local time is 10:00 CET, displayed as 12:00 CET)

Expected results:

The time should be displayed correctly.

Additional info:

After a user is logged in, the time displayed on the panel is correct.
Comment 1 Christoph Wickert 2013-06-04 07:15:39 EDT
Please give me the output of "timedatectl" and tell me what lxdm displays meanwhile.
Comment 2 Jean-Pierre André 2013-06-05 03:37:37 EDT
How should I start timedatectl so that it is executed before a user is logged in ?
After a user is logged in, the time display is correct. Also I noticed that it takes 10-15s from inputting the password to getting the desktop display, so most of the kernel modules are not yet loaded when the logging screen is displayed.
Comment 3 Christoph Wickert 2013-06-05 06:29:05 EDT
1. Press CTRL+ALT and F2 to get to a text console. Log in and issue the command like so "timedatectl > time.txt"
2. Log out by typing "exit"
3. Press CTRL+ALT and F1 to get back to lxdm. Log in, open the file time.txt with an editor and post it's contents here.

Thanks!
Comment 4 Jean-Pierre André 2013-06-07 11:50:57 EDT
The situation might be more complex than I thought, so I rechecked all again. I numbered the actions for easier further reference.

First of all, below are the conditions of the initial report :

With the procedure you suggest I have to login into the second text console. Doing so takes some time (say 10s), and when returning to the graphical console is enough to get the correct time displayed.

To get a meaningful situation, I have to pre-enter the command in such a place it gets executed before anybody logs in.

1) Anyway, first I made sure the time on Windows was correct (about 18h48), then I booted into Fedora 19.

2) This is what was output by timedatectl while doing what you suggested (before logging in the time was displayed as 06:50:xx PM) :

[linux@dimension c-src]$ cat time.txt
      Local time: Fri 2013-06-07 16:51:46 CEST
  Universal time: Fri 2013-06-07 14:51:46 UTC
        Timezone: Europe/Paris (CEST, +0200)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2013-03-31 01:59:59 CET
                  Sun 2013-03-31 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2013-10-27 02:59:59 CEST
                  Sun 2013-10-27 02:00:00 CET

3) When I got back to the graphic screen, I got the correct time displayed (still on the login screen), and I logged in.

4) As I got surprised by "RTC not in local TZ", and I checked the setting by starting "system-config-date". The "Use Local Time Source" checkbox was off.
Strange, because the synchronisation with Windows is correct, and this is the setting I need.

5) Now, I checked "Use Local Time Source" on, and rebooted into Windows. So from now on the conditions are not those of the initial report.

6) On Windows, the clock became two hours slow, so I fixed it.

7) I rebooted into Fedora 9, repeating the procedure. On the initial login screen, the time was correct. On the CtrlAltF2 terminal, I got :

[linux@dimension c-src]$ cat time2.txt
      Local time: Fri 2013-06-07 17:12:36 CEST
  Universal time: Fri 2013-06-07 15:12:36 UTC
        Timezone: Europe/Paris (CEST, +0200)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2013-03-31 01:59:59 CET
                  Sun 2013-03-31 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2013-10-27 02:59:59 CEST
                  Sun 2013-10-27 02:00:00 CET

Note : the RTC is still marked not in local time zone.

8) Back to the graphic screen, I logged in, to see the clock was by now fast by two hours. I made sure that in system-config-date the "Use Local Time Source" checkbox was still marked, and I adjusted the clock to correct local time.

9) Booting again to Windows, the clock was slow by two hours, so I fixed it.

10)  I returned to the initial settings in Fedora 19 : this is obviously what I need.

The "RTC in local TZ" flag does not appear to be processed correctly in the LXDE environment...
Comment 5 Jean-Pierre André 2013-06-07 11:56:37 EDT
In comment 4, step 1), please read "the time on Windows was about 16h48 (04:48 PM)". Sorry for the typo.
Comment 6 Leslie Satenstein 2014-04-14 11:42:02 EDT
This is a Fedora 20 bug as well as a Fedora 19 bug

Here are two outputs with timedatectl.
This is without the setting enabled for automatic timezone 
timedatectl yields

Local time: Sat 2014-04-12 12:03:03 EDT
Universal time: Sat 2014-04-12 16:03:03 UTC
RTC time: Sat 2014-04-12 12:03:03
Timezone: America/New_York (EDT, -0400)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: yes
DST active: yes
Last DST change: DST began at
Sun 2014-03-09 01:59:59 EST
Sun 2014-03-09 03:00:00 EDT
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2014-11-02 01:59:59 EDT
Sun 2014-11-02 01:00:00 EST

Warning: The RTC is configured to maintain time in the local timezone. This
mode is not fully supported and will create various problems with time
zone changes and daylight saving adjustments. If at all possible use
RTC in UTC, by calling 'timedatectl set-local-rtc 0'.

The instant I turned automatic timezone setting to On
I got the message about cdt, had the clock go back one hour.


Here is the update you will notice the change from EDT to CDT.

timedatectl

Local time: Sat 2014-04-12 11:05:21 CDT
Universal time: Sat 2014-04-12 16:05:21 UTC
RTC time: Sat 2014-04-12 11:05:21
Timezone: America/Winnipeg (CDT, -0500)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: yes
DST active: yes
Last DST change: DST began at
Sun 2014-03-09 01:59:59 CST
Sun 2014-03-09 03:00:00 CDT
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2014-11-02 01:59:59 CDT
Sun 2014-11-02 01:00:00 CST

Warning: The RTC is configured to maintain time in the local timezone. This
mode is not fully supported and will create various problems with time
zone changes and daylight saving adjustments. If at all possible use
RTC in UTC, by calling 'timedatectl set-local-rtc 0'. 

Can someone confirm that the ISP is sending the wrong information to the software, or that the software is just "broken" and needs fixing.

Automatic timezone is disabled for localtime to show correctly.
Comment 7 Leslie Satenstein 2014-04-14 11:49:04 EDT
Do I need to re-file for Fedora 20?
Comment 8 Fedora End Of Life 2015-01-09 13:19:13 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 9 Fedora End Of Life 2015-02-17 10:26:56 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.