I'm not sure where to report this:
I have three 24-hour TDE clocks in a panel: one on local time; one on London time; and one on UTC. The London and UTC clocks are reading the same time, but I discovered yesterday that in fact London is already on summer time (and has been for nearly a week, I understand), so the London time should be displaying a number one hour higher than UTC.
Doc
On Friday 30 March 2018 09:08:54 D. R. Evans wrote:
I'm not sure where to report this:
I have three 24-hour TDE clocks in a panel: one on local time; one on London time; and one on UTC. The London and UTC clocks are reading the same time, but I discovered yesterday that in fact London is already on summer time (and has been for nearly a week, I understand), so the London time should be displaying a number one hour higher than UTC.
Doc
I've noticed that there is sometimes a lag for the time change. It must be something to do with time servers, and what gets communicated globally. I'm not sure if this quite answers your question, though.
My mobile phone, for example, always changes time a week earlier than the actual local date for beginning and end of daylight savings time. A similar glitch occurs with my digital television, except that there it is always late to change. On the other hand, the time on my computer seems to be consistent and reliable; but then, I don't have a set-up like yours, where I can see the difference between UTC and GMT in real time.
Bill
On Friday 30 March 2018 09:08:54 D. R. Evans wrote:
I'm not sure where to report this:
I have three 24-hour TDE clocks in a panel: one on local time; one on London time; and one on UTC. The London and UTC clocks are reading the same time, but I discovered yesterday that in fact London is already on summer time (and has been for nearly a week, I understand), so the London time should be displaying a number one hour higher than UTC.
I have more info on this now, but still don't know where best to report it.
The additional info is that logging out and logging back in -- which is something I rarely do; I often go weeks without doing so, but I happened to do it today -- "fixed" the problem.
So what appears to happen (this is a guess, but it fits the evidence) is that the clock figures out the time in London at log-in time, and then starts free-running, keeping the same offset between the displayed time and UTC, regardless of subsequent changes to/from summer time that might occur during the logged-in session.
In any case, the fact that the clock is unreliable and can display an incorrect time is obviously a bug, and I would hope that someone can look into the issue. (FWIW, the local clock -- Denver -- quite happily adjusted the time automatically and correctly earlier in the month.)
Doc
On Friday 30 March 2018 16:36:19 D. R. Evans wrote:
On Friday 30 March 2018 09:08:54 D. R. Evans wrote:
I'm not sure where to report this:
I have three 24-hour TDE clocks in a panel: one on local time; one on London time; and one on UTC. The London and UTC clocks are reading the same time, but I discovered yesterday that in fact London is already on summer time (and has been for nearly a week, I understand), so the London time should be displaying a number one hour higher than UTC.
I have more info on this now, but still don't know where best to report it.
The additional info is that logging out and logging back in -- which is something I rarely do; I often go weeks without doing so, but I happened to do it today -- "fixed" the problem.
So what appears to happen (this is a guess, but it fits the evidence) is that the clock figures out the time in London at log-in time, and then starts free-running, keeping the same offset between the displayed time and UTC, regardless of subsequent changes to/from summer time that might occur during the logged-in session.
In any case, the fact that the clock is unreliable and can display an incorrect time is obviously a bug, and I would hope that someone can look into the issue. (FWIW, the local clock -- Denver -- quite happily adjusted the time automatically and correctly earlier in the month.)
Doc
This doesn't happen on my system. It makes no difference if I stay in the same session continuously for days or even weeks without rebooting, or a new log-in.
I have actually watched the clock on my desktop at the moment the time changes for daylight savings, or changes back in the fall; it just automatically skips an hour, forwards or backwards, at 2 a.m. I just watched this happen a few weeks ago (11th of March) when the time changed here locally.
Then again, I only use one clock, not three. It could be that they somehow interfere with one another; but it sounds like maybe this is your customary setup? (I chat with people in many different time zones, but I just mark different cities in my clock, then change my local time. Or, I use the very handy Trinity World Clock. Otherwise, I have a time zone map for reference.)
Otherwise, maybe the bug is in your version of Trinity, or is in your OS. I run Debian Jessie, with the Trinity r14.0.4 desktop. What are you running?
Bill
Hi,
The additional info is that logging out and logging back in -- which is something I rarely do; I often go weeks without doing so, but I happened to do it today -- "fixed" the problem.
It seems that your clock will set at login time perhaps you set/use different timezones for the clocks.
I usually use ntpd to sync my clock via internet. But make shure your clock has less then 1 or 2 minute differenc to utc. Best is: - stop the utp daemon - use ntpdate to correct you clock - perhaps use 'hwclock -w' to adjust the hardware clock too. - start ntpd again. Now the clock will be adjusted continusly (I don't know the length of the intevall between two updates).
HTH Rolf
On Saturday 31 March 2018 02:08:12 Rolf Schmidt wrote:
Hi,
The additional info is that logging out and logging back in -- which is something I rarely do; I often go weeks without doing so, but I happened to do it today -- "fixed" the problem.
It seems that your clock will set at login time perhaps you set/use different timezones for the clocks.
I usually use ntpd to sync my clock via internet. But make shure your clock has less then 1 or 2 minute differenc to utc. Best is:
- stop the utp daemon
- use ntpdate to correct you clock
- perhaps use 'hwclock -w' to adjust the hardware clock too.
- start ntpd again.
Now the clock will be adjusted continusly (I don't know the length of the intevall between two updates).
HTH Rolf
You might find these two webpages to be useful: https://blog.hboeck.de/archives/890-In-Search-of-a-Secure-Time-Source.html This page gives a bash script: date -s "$(curl -sI https://www.google.com/%7Cgrep -i 'date:'| sed -e 's/^.ate: //g')" I adapted this to use DDG instead of Google; works pretty well. It seems not very secure, though, and you may find that now your system time is now a little "off" - by several seconds or more, compared to other online devices - although maybe it's better than off by an hour.
At the end of the page I've cited above is a link to another bash script: https://github.com/hannob/httpstime/blob/master/httpstime
Bill
On Saturday 31 March 2018 05:08:12 Rolf Schmidt wrote:
Hi,
The additional info is that logging out and logging back in -- which is something I rarely do; I often go weeks without doing so, but I happened to do it today -- "fixed" the problem.
It seems that your clock will set at login time perhaps you set/use different timezones for the clocks.
I usually use ntpd to sync my clock via internet. But make shure your clock has less then 1 or 2 minute differenc to utc. Best is:
- stop the ntp daemon
- use ntpdate to correct you clock
- perhaps use 'hwclock -w' to adjust the hardware clock too.
- start ntpd again.
Now the clock will be adjusted continusly (I don't know the length of the intevall between two updates).
HTH Rolf
I did find one reference to about 1.1 hours between updates. I'd assume, having dealt with this before when mobo clocks weren't so accurate, (I've had a linux only house since 1998) ntp claimed to adjust this interval, and later to adjust the clock's drift so it eventually settled to a very small error and the update rate would fall back to the default. No idea if this is still true, and the man pages seem to have been eviscerated of such info. Sad state of affairs IMNSHO.
D. R. Evans wrote on 03/30/2018 10:08 AM:
I'm not sure where to report this:
I didn't see any reply that suggested where I should report the problem regarding the London time (which, incidentally, has nothing to do with NTP or the hardware clock). That's really what I was looking for: some way to report the problem somewhere where someone who might be able to fix it would probably see it. Does anyone have any suggestions as to where that "somewhere" might be?
Doc
Am Donnerstag 05 April 2018 schrieb D. R. Evans:
D. R. Evans wrote on 03/30/2018 10:08 AM:
I'm not sure where to report this:
I didn't see any reply that suggested where I should report the problem regarding the London time (which, incidentally, has nothing to do with NTP or the hardware clock).
Yes, you should see a drift or one hour offset on all of the clocks you configured in kicker and in other applications including the date command, too, if ntp or hardware clock is the issue, I think.
That's really what I was looking for: some way to report the problem somewhere where someone who might be able to fix it would probably see it. Does anyone have any suggestions as to where that "somewhere" might be?
Doc
So far as I understand what you reported it's not clear as to where the problem is rooted which to know would be necessary to decide to whom to report to.
If the kicker clockapplet misses to update regularly without logging in/out, then it might be the source of the symptoms you observed, but then, I guess, clockapplet should also fail to update summer-/wintertime switches not only with one London clock but also the other Denver one you mentioned, shouldn't it?
Just tried: kicker clockapplet seems to immediately update correctly when you switch timezones…
Stefan
-
D. R. Evans -
Gene Heskett -
Rolf Schmidt -
Stefan Krusche -
William Morder