• Gnome Desktop Time Entry 1 Hour Later

    From Jim Beard@2:250/1 to All on Sun Nov 15 17:30:15 2020

    If I run date from a command line, I get the correct time, on both my
    main machine and my backup.

    On both, if I load the Gnome desktop, the date-time that appears on the
    top bar across the screen is 1 hour later than it should be.

    Does anyone else have the problem?

    Any idea how to fix it? I look around a bit and suspect systemd may be involved...

    Cheers!

    jim b.

    --
    UNIX is not user-unfriendly, it merely expects users to be computer-
    friendly.

    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Sun Nov 15 17:50:27 2020
    On 2020-11-15, Jim Beard <jim.beard@verizon.net> wrote:

    If I run date from a command line, I get the correct time, on both my
    main machine and my backup.

    Wnat does date -utc say?

    Is your RTC on local time or on UTC?

    What is the file /etc/localtime. Is it a link and if so what does it
    point to? What timezone are you in and what timezone does you machine
    work in?

    Are you running an NTP program (ntpd or chrony)?



    On both, if I load the Gnome desktop, the date-time that appears on the
    top bar across the screen is 1 hour later than it should be.

    Does anyone else have the problem?

    Any idea how to fix it? I look around a bit and suspect systemd may be involved...

    I doubt it. systemd has to do with system stuff, not Gnome. I think it
    is a Gnome problem. For some reason gnome might be confused as to
    daylight savings time.

    Cheers!

    jim b.


    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Jim Beard@2:250/1 to All on Sun Nov 15 18:33:27 2020
    On Sun, 15 Nov 2020 17:50:27 +0000, William Unruh wrote:

    On 2020-11-15, Jim Beard <jim.beard@verizon.net> wrote:

    If I run date from a command line, I get the correct time, on both my
    main machine and my backup.

    Wnat does date -utc say?

    $ date -utc
    date: invalid option -- 't'
    Try 'date --help' for more information.

    Is your RTC on local time or on UTC?

    timedatectl
    Local time: Sun 2020-11-15 13:28:25 EST
    Universal time: Sun 2020-11-15 18:28:25 UTC
    RTC time: Sun 2020-11-15 18:28:25
    Time zone: America/New_York (EST, -0500)
    System clock synchronized: yes
    NTP service: inactive
    RTC in local TZ: no

    Despite the above /usr/sbin/chronyd is running and the time displayed by
    Gnome desktop in the top bar is 14:28:25.

    What is the file /etc/localtime. Is it a link and if so what does it
    point to? What timezone are you in and what timezone does you machine
    work in?

    link
    localtime -> /usr/share/zoneinfo/America/New_York
    See output from timedatectl above.

    Are you running an NTP program (ntpd or chrony)?

    When checked, my main machine was running neither, but should have been running chronyd. Perhaps I somehow killed it. In mcc/system services I killed it and started it up again, and chrony is now running. No change
    in top bar time.

    My backup machine was and is running chrony. Time appearing in the top
    bar is the same, 1 hour later than it should be.

    On both, if I load the Gnome desktop, the date-time that appears on the
    top bar across the screen is 1 hour later than it should be.

    Does anyone else have the problem?

    Any idea how to fix it? I look around a bit and suspect systemd may be
    involved...

    I doubt it. systemd has to do with system stuff, not Gnome. I think it
    is a Gnome problem. For some reason gnome might be confused as to
    daylight savings time.

    Cheers!

    jim b.

    --
    UNIX is not user-unfriendly, it merely expects users to be computer-
    friendly.

    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Mike Easter@2:250/1 to All on Sun Nov 15 19:38:37 2020
    Jim Beard wrote:
    William Unruh wrote:

    Wnat does date -utc say?

    $ date -utc
    date: invalid option -- 't'
    Try 'date --help' for more information.

    date utc syntax is date --utc or date -u

    date --help shows that option info.

    --
    Mike Easter

    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sun Nov 15 19:48:32 2020
    Bug confirmed.

    https://bugs.mageia.org/show_bug.cgi?id=27609

    While gnome applications appear to be displaying the time assuming that daylight
    saving time is still in effect, kde plasma and system applications correctly display the time recognizing that the local time is now standard time.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Sun Nov 15 20:10:03 2020
    On 2020-11-15, Jim Beard <jim.beard@verizon.net> wrote:
    On Sun, 15 Nov 2020 17:50:27 +0000, William Unruh wrote:

    On 2020-11-15, Jim Beard <jim.beard@verizon.net> wrote:

    If I run date from a command line, I get the correct time, on both my
    main machine and my backup.

    Wnat does date -utc say?

    $ date -utc
    date: invalid option -- 't'
    Try 'date --help' for more information.

    Ooops sorry. date --utc


    Is your RTC on local time or on UTC?

    timedatectl
    Local time: Sun 2020-11-15 13:28:25 EST
    Universal time: Sun 2020-11-15 18:28:25 UTC
    RTC time: Sun 2020-11-15 18:28:25
    Time zone: America/New_York (EST, -0500)
    System clock synchronized: yes
    NTP service: inactive
    RTC in local TZ: no

    Despite the above /usr/sbin/chronyd is running and the time displayed by Gnome desktop in the top bar is 14:28:25.

    It probably does not recognize chrony as an ntp server.
    OK your system is behaving properly. That strengthens my belief that it
    is not a systemd problem, but a Gnome problem. For some reason it still
    thinks it is on DST.

    What is the file /etc/localtime. Is it a link and if so what does it
    point to? What timezone are you in and what timezone does you machine
    work in?

    link
    localtime -> /usr/share/zoneinfo/America/New_York
    See output from timedatectl above.

    Are you running an NTP program (ntpd or chrony)?

    When checked, my main machine was running neither, but should have been running chronyd. Perhaps I somehow killed it. In mcc/system services I killed it and started it up again, and chrony is now running. No change
    in top bar time.

    My backup machine was and is running chrony. Time appearing in the top
    bar is the same, 1 hour later than it should be.

    On both, if I load the Gnome desktop, the date-time that appears on the
    top bar across the screen is 1 hour later than it should be.

    Does anyone else have the problem?

    Any idea how to fix it? I look around a bit and suspect systemd may be
    involved...

    I doubt it. systemd has to do with system stuff, not Gnome. I think it
    is a Gnome problem. For some reason gnome might be confused as to
    daylight savings time.

    Cheers!

    jim b.


    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Jim Beard@2:250/1 to All on Sun Nov 15 20:20:50 2020
    On Sun, 15 Nov 2020 14:48:32 -0500, David W. Hodgins wrote:

    Bug confirmed.

    https://bugs.mageia.org/show_bug.cgi?id=27609

    While gnome applications appear to be displaying the time assuming that daylight saving time is still in effect, kde plasma and system
    applications correctly display the time recognizing that the local time
    is now standard time.

    Regards, Dave Hodgins

    Thank you.

    Cheers!

    jim b.

    --
    UNIX is not user-unfriendly, it merely expects users to be computer-
    friendly.

    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Doug Laidlaw@2:250/1 to All on Mon Nov 16 09:38:07 2020
    On 16/11/20 6:48 am, David W. Hodgins wrote:
    Bug confirmed.

    https://bugs.mageia.org/show_bug.cgi?id=27609

    While gnome applications appear to be displaying the time assuming that daylight
    saving time is still in effect, kde plasma and system applications
    correctly
    display the time recognizing that the local time is now standard time.

    Regards, Dave Hodgins

    Daylight saving was the explanation in my case. Australia is on Summer
    Time. I have exactly the same scenario as Jim: everything shows the
    correct time except the clock in the system tray, which is stuck on
    standard time, 1 hour earlier. My system clock is set to GMT. My
    desktop is XFCE, which I think, borrows a lot from GNOME. As I recall,
    KDE has an independent setting for the desktop. I haven't yet found one
    for Xfce.

    Doug.

    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (2:250/1@fidonet)
  • From Jim Beard@2:250/1 to All on Mon Nov 16 14:46:19 2020
    On Mon, 16 Nov 2020 20:38:07 +1100, Doug Laidlaw wrote:

    On 16/11/20 6:48 am, David W. Hodgins wrote:
    Bug confirmed.

    https://bugs.mageia.org/show_bug.cgi?id=27609

    While gnome applications appear to be displaying the time assuming that
    daylight saving time is still in effect, kde plasma and system
    applications correctly display the time recognizing that the local time
    is now standard time.

    Regards, Dave Hodgins

    Daylight saving was the explanation in my case. Australia is on Summer
    Time. I have exactly the same scenario as Jim: everything shows the
    correct time except the clock in the system tray, which is stuck on
    standard time, 1 hour earlier. My system clock is set to GMT. My
    desktop is XFCE, which I think, borrows a lot from GNOME. As I recall,
    KDE has an independent setting for the desktop. I haven't yet found one
    for Xfce.

    You might add your XFCE instance to the bug at Mageia. They will pass
    it on to upstream.

    https://bugs.mageia.org/show_bug.cgi?id=27609

    Cheers!

    jim .

    --
    UNIX is not user-unfriendly, it merely expects users to be computer-
    friendly.

    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Mon Nov 16 16:24:40 2020
    On 2020-11-16, Jim Beard <jim.beard@verizon.net> wrote:
    On Mon, 16 Nov 2020 20:38:07 +1100, Doug Laidlaw wrote:

    On 16/11/20 6:48 am, David W. Hodgins wrote:
    Bug confirmed.

    https://bugs.mageia.org/show_bug.cgi?id=27609

    While gnome applications appear to be displaying the time assuming that
    daylight saving time is still in effect, kde plasma and system
    applications correctly display the time recognizing that the local time
    is now standard time.

    Regards, Dave Hodgins

    Daylight saving was the explanation in my case. Australia is on Summer
    Time. I have exactly the same scenario as Jim: everything shows the
    correct time except the clock in the system tray, which is stuck on
    standard time, 1 hour earlier. My system clock is set to GMT. My
    desktop is XFCE, which I think, borrows a lot from GNOME. As I recall,
    KDE has an independent setting for the desktop. I haven't yet found one
    for Xfce.

    You might add your XFCE instance to the bug at Mageia. They will pass
    it on to upstream.

    https://bugs.mageia.org/show_bug.cgi?id=27609

    Good idea. But you could also install an earlier version of the timezone
    rpm. (eg timezone-2019c-1.mga7)
    https://bugs.mageia.org/show_bug.cgi?id=27610
    says that one works.
    Also try
    zdump -v -c 2019,2021 /etc/localtime
    (replace America/Vancouver with your own particular time zone
    to see when the tzdata file thinks DST begins and this year.
    (although I suspect that this is OK since the date command works).


    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Mon Nov 16 17:46:37 2020
    On 2020-11-16, William Unruh <unruh@invalid.ca> wrote:
    On 2020-11-16, Jim Beard <jim.beard@verizon.net> wrote:
    On Mon, 16 Nov 2020 20:38:07 +1100, Doug Laidlaw wrote:

    On 16/11/20 6:48 am, David W. Hodgins wrote:
    Bug confirmed.

    https://bugs.mageia.org/show_bug.cgi?id=27609

    While gnome applications appear to be displaying the time assuming that >>>> daylight saving time is still in effect, kde plasma and system
    applications correctly display the time recognizing that the local time >>>> is now standard time.

    Regards, Dave Hodgins

    Daylight saving was the explanation in my case. Australia is on Summer
    Time. I have exactly the same scenario as Jim: everything shows the
    correct time except the clock in the system tray, which is stuck on
    standard time, 1 hour earlier. My system clock is set to GMT. My
    desktop is XFCE, which I think, borrows a lot from GNOME. As I recall,
    KDE has an independent setting for the desktop. I haven't yet found one >>> for Xfce.

    You might add your XFCE instance to the bug at Mageia. They will pass
    it on to upstream.

    https://bugs.mageia.org/show_bug.cgi?id=27609

    Good idea. But you could also install an earlier version of the timezone
    rpm. (eg timezone-2019c-1.mga7) https://bugs.mageia.org/show_bug.cgi?id=27610
    says that one works.
    Also try
    zdump -v -c 2019,2021 /etc/localtime
    (replace America/Vancouver with your own particular time zone
    to see when the tzdata file thinks DST begins and this year.
    (although I suspect that this is OK since the date command works).

    It would seem that Gnome "rolled their own" as far as the timezone/DST
    was concerned, instead of using of using the timezone database and the
    standard linux gettimeofday routines. https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/139
    shows that this has been a problem for years in gnome, with no intention
    it appears of fixing it. (https://unix.stackexchange.com/questions/362250/is-my-bst-time-zone-an-hour-be hind
    shows it is at least 3 1/2 years old. No wonder many despise Gnome.)


    See also https://community.clearlinux.org/t/daylight-savings-in-gnome-3-38-not-displayin g-correctly-in-gnome-panel/5671/3
    where it is claimed that Fedora and Canonical have patches but give no pointers.




    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Jim Beard@2:250/1 to All on Tue Nov 17 15:27:42 2020
    On Mon, 16 Nov 2020 17:46:37 +0000, William Unruh wrote:


    It would seem that Gnome "rolled their own" as far as the timezone/DST
    was concerned, instead of using of using the timezone database and the standard linux gettimeofday routines. https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/139 shows that
    this has been a problem for years in gnome, with no intention it appears
    of fixing it. (https://unix.stackexchange.com/questions/362250/is-my-bst-time-zone- an-hour-behind shows it is at least 3 1/2 years old. No wonder many
    despise Gnome.)

    See also https://community.clearlinux.org/t/daylight-savings-in-gnome-3-38-not-
    displaying-correctly-in-gnome-panel/5671/3
    where it is claimed that Fedora and Canonical have patches but give no pointers.

    Fascinating I suppose, but the current instance of the problem appears
    to be in glib2. An update available on the mirrors should correct it.

    MGAA-2020-0231 - Updated glib2/timezone packages fix date shown in gnome desktop

    Cheers!

    jim b.

    --
    UNIX is not user-unfriendly, it merely expects users to be computer-
    friendly.

    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Tue Nov 17 19:11:14 2020
    On 2020-11-17, Jim Beard <jim.beard@verizon.net> wrote:
    On Mon, 16 Nov 2020 17:46:37 +0000, William Unruh wrote:


    It would seem that Gnome "rolled their own" as far as the timezone/DST
    was concerned, instead of using of using the timezone database and the
    standard linux gettimeofday routines.
    https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/139 shows that
    this has been a problem for years in gnome, with no intention it appears
    of fixing it.
    (https://unix.stackexchange.com/questions/362250/is-my-bst-time-zone-
    an-hour-behind shows it is at least 3 1/2 years old. No wonder many
    despise Gnome.)

    See also
    https://community.clearlinux.org/t/daylight-savings-in-gnome-3-38-not-
    displaying-correctly-in-gnome-panel/5671/3
    where it is claimed that Fedora and Canonical have patches but give no
    pointers.

    Fascinating I suppose, but the current instance of the problem appears
    to be in glib2. An update available on the mirrors should correct it.

    MGAA-2020-0231 - Updated glib2/timezone packages fix date shown in gnome desktop

    This is very strange, since you say that "date" gives the right time.
    date surely uses the same glib that gnome does. And KDE also does not have this problem.



    Cheers!

    jim b.


    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Tue Nov 17 22:53:34 2020
    On Tue, 17 Nov 2020 14:11:14 -0500, William Unruh <unruh@invalid.ca> wrote:

    This is very strange, since you say that "date" gives the right time.
    date surely uses the same glib that gnome does. And KDE also does not have this problem.

    They use different options when getting the local time. KDE and the system utilities use the same one. Gnome uses a new option that while available in cauldron, was not available in the glibc used in Mageia 7.

    The bug is only noticeable if you're using gnome and pay attention to the
    time at the top of the screen.

    https://bugs.mageia.org/show_bug.cgi?id=27609#c11

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Wed Nov 18 00:01:07 2020
    On 2020-11-17, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Tue, 17 Nov 2020 14:11:14 -0500, William Unruh <unruh@invalid.ca> wrote:

    This is very strange, since you say that "date" gives the right time.
    date surely uses the same glib that gnome does. And KDE also does not have >> this problem.

    They use different options when getting the local time. KDE and the system utilities use the same one. Gnome uses a new option that while available in cauldron, was not available in the glibc used in Mageia 7.

    The bug is only noticeable if you're using gnome and pay attention to the time at the top of the screen.

    https://bugs.mageia.org/show_bug.cgi?id=27609#c11

    I have read that and chased up the Makefile for zic etc. But I still do
    not understand why gnome would differ from date or kde. I would assume
    both would use the gettimeofday function to get the time. Or does gnome
    really "roll their own" and read the /etc/localtime (or whichever
    timezone file from the /usr/share/zoneinfo file it needs) directly and
    then interpret the UTC seconds it gets from the system clock
    into a human date and time with its own interpretation of the zoneinfo
    file. That would be dumb if it did that. System libraries are there for
    a reason, and using them makes sure that bugs are caught easily (they
    affet everyone) and can be fixed in one place, not 100000 different
    places.


    Regards, Dave Hodgins


    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Wed Nov 18 01:18:46 2020
    On Tue, 17 Nov 2020 19:01:07 -0500, William Unruh <unruh@invalid.ca> wrote:
    On 2020-11-17, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    The bug is only noticeable if you're using gnome and pay attention to the
    time at the top of the screen.
    https://bugs.mageia.org/show_bug.cgi?id=27609#c11

    I have read that and chased up the Makefile for zic etc. But I still do
    not understand why gnome would differ from date or kde. I would assume

    I haven't looked into the internals of how the gnome desktop obtains the current
    local time or how it differs from other environments. As long as the update fixes
    it (which it does), I've got other things I'd rather spend my time on. :-)

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Jim Beard@2:250/1 to All on Wed Nov 18 14:52:05 2020
    On Wed, 18 Nov 2020 00:01:07 +0000, William Unruh wrote:

    On 2020-11-17, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Tue, 17 Nov 2020 14:11:14 -0500, William Unruh <unruh@invalid.ca>
    wrote:

    This is very strange, since you say that "date" gives the right time.
    date surely uses the same glib that gnome does. And KDE also does not
    have this problem.

    They use different options when getting the local time. KDE and the
    system utilities use the same one. Gnome uses a new option that while
    available in cauldron, was not available in the glibc used in Mageia 7.

    The bug is only noticeable if you're using gnome and pay attention to
    the time at the top of the screen.

    https://bugs.mageia.org/show_bug.cgi?id=27609#c11

    I have read that and chased up the Makefile for zic etc. But I still do
    not understand why gnome would differ from date or kde. I would assume
    both would use the gettimeofday function to get the time. Or does gnome really "roll their own" and read the /etc/localtime (or whichever
    timezone file from the /usr/share/zoneinfo file it needs) directly and
    then interpret the UTC seconds it gets from the system clock into a
    human date and time with its own interpretation of the zoneinfo file.
    That would be dumb if it did that. System libraries are there for a
    reason, and using them makes sure that bugs are caught easily (they
    affet everyone) and can be fixed in one place, not 100000 different
    places.
    Regards, Dave Hodgins

    I think we need a Gnome historian, but it looks to me as if Gnome
    created the glib utilities and libraries for use in gnome desktop,
    and kde and others adopted it.

    Now, Gnome has enhanced glib2 in a manner that causes earlier versions
    of the Gnome desktop to bungle handling of timezone. That does not
    seem to affect other desktops, that presumably have not incorporated
    the new enhancement in question.

    The problem in the Gnome desktop has been dealt with, and presumably
    will be dealt with in other desktops when they take advantage of the
    new enhancement.

    Cheers!

    jim b.

    --
    UNIX is not user-unfriendly, it merely expects users to be computer-
    friendly.

    --- MBSE BBS v1.0.7.17 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)