30 Mar
2018
30 Mar
'18
4:08 p.m.
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
--
Web: http://enginehousebooks.com/drevans
30 Mar
30 Mar
5:32 p.m.
New subject: [trinity-users] Incorrect digital clock time
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
11:36 p.m.
New subject: [trinity-users] Incorrect digital clock time
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
--
Web: http://enginehousebooks.com/drevans
31 Mar
31 Mar
1:14 a.m.
New subject: [trinity-users] Incorrect digital clock time
On Friday 30 March 2018 16:36:19 D. R. Evans wrote:
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
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 
9:08 a.m.
New subject: [trinity-users] Incorrect digital clock time
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
1:01 p.m.
New subject: [trinity-users] Incorrect digital clock time
On Saturday 31 March 2018 02:08:12 Rolf Schmidt wrote:
Hi,
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/|grep -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
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 
1:23 p.m.
New subject: [trinity-users] Incorrect digital clock time
On Saturday 31 March 2018 05:08:12 Rolf Schmidt wrote:
Hi,
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.
--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
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
5 Apr
5 Apr
1:18 p.m.
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
--
Web: http://enginehousebooks.com/drevans
2:31 p.m.
New subject: [trinity-users] Re: Incorrect digital clock time
Am Donnerstag 05 April 2018 schrieb D. R. Evans:
D. R. Evans wrote on 03/30/2018 10:08 AM:
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.
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
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
2452
days inactive
2458
days old
8 comments
5 participants
participants (5)
-
D. R. Evans -
Gene Heskett -
Rolf Schmidt -
Stefan Krusche -
William Morder