SEO

pls. redirect if this group is wrong, couldn't find a better one in
short time,

searchwords: leap seconds timezone rtc cmos clock hwclock clockspeed
date time

problem: in short: hwclock seems to handle 'leapseconds' in a wrong
way, leading to wrong time settings,

problem occurred on systems set up with 'right' zonefiles to use
clockspeed, leap seconds and the 'djb-way', which are no longer
'posix' conform,

error occurring:
'hwclock --utc --systohc'
will set the rtc to a time something about 22 or 23 seconds behind
system time, i think this is the wrong point,
'hwclock --utc --hctosys'
'corrects' the system time exactly to rtc time,
thus repeatedly executing both commands will let you set back both
time values, what - posix or not, djb-way right or not - is definitely
not what anyone wants.

problem on real systems: as many linux installations set system time
from rtc on boot, and write back system time to rtc on shutdown,
systems without external time correction will be off 22 more seconds
with every reboot, and systems with external time correction
(clockspeed, ntp, xntp, dfc77, ...) will be off for 22 seconds on boot
(or any other value acc. to the rtc drift when you suppress the
writeback on shutdown or on 'hard' shutoffs).

my idea where to search: i think hwclock uses different routines or
system calls or options for the calculation of the time values, one
respecting leap seconds, the other ignoring them, debugging this is
far beyond my scope, so i'd like someone else to look for it,

as far as the problem might be system specific: primergy tx 150 s5
sata, sles 10 sp1 (suse linux enterprise server), both versions (32
and 64 bit) mostly standard fresh installed system, changes to
standard:
ln -s /etc/localtime /usr/share/zoneinfo/right/Europe/Berlin,
/etc/leapsecs.dat existing (don't know if from sles or install of
clockspeed),

my idea is the problem is general and will show up on most systems an
installations when you start using tai and leapseconds,

procedure to reproduce: set up your system to work with leapseconds,
mostly covered by the two steps above (google for djb, clockspeed and
leapseconds for more info), then execute:
date
hwclock --systohc --utc
hwclock --hctosys --utc
date
repeatedly, you can use a batch, and see if your system clock changes
backwards.

one possible but dirty workaround: use the 'wrong' standard zoneinfo
files and kill the leapseconds info by renaming /etc/leapsecs.dat,
really dirty, but i'll do until problem is solved,

pls don't complain this being a minor or exotic problem, which is
overruled by use of external timesources, or suppressed by using
'posix' standards, affecting only a short time in computer life
(boot), one should not configure a system that way when no external
time source is avaiable, djb being wrong, or things like this, it is!
a malfunction, or at least something 'unusual', it wasted my time to
check out, and it is good if someone can shed so much light on it that
others do not do the some (waste time),

a helpless user

pls don't complain for missing full name, it's my privacy and
complaining only wastes time,

On 1 Jan, 18:52, [email protected] wrote:
> pls. redirect if this group is wrong, couldn't find a better one in
> short time,
>
> searchwords: leap seconds timezone rtc cmos clock hwclock clockspeed
> date time
>
> problem: in short: hwclock seems to handle 'leapseconds' in a wrong
> way, leading to wrong time settings,
>
> problem occurred on systems set up with 'right' zonefiles to use
> clockspeed, leap seconds and the 'djb-way', which are no longer
> 'posix' conform,
>
> error occurring:
> 'hwclock --utc --systohc'
> will set the rtc to a time something about 22 or 23 seconds behind
> system time, i think this is the wrong point,
> 'hwclock --utc --hctosys'
> 'corrects' the system time exactly to rtc time,
> thus repeatedly executing both commands will let you set back both
> time values, what - posix or not, djb-way right or not - is definitely
> not what anyone wants.

This may not be what you want, but why aren't you using NTP to
synchronize with the more accurate global clock services?

Nico Kadel-Garcia ([email protected]) writes:
> On 1 Jan, 18:52, [email protected] wrote:
>> pls. redirect if this group is wrong, couldn't find a better one in
>> short time,
>>
>> searchwords: leap seconds timezone rtc cmos clock hwclock clockspeed
>> date time
>>
>> problem: in short: hwclock seems to handle 'leapseconds' in a wrong
>> way, leading to wrong time settings,
>>
>> problem occurred on systems set up with 'right' zonefiles to use
>> clockspeed, leap seconds and the 'djb-way', which are no longer
>> 'posix' conform,
>>
>> error occurring:
>> 'hwclock --utc --systohc'
>> will set the rtc to a time something about 22 or 23 seconds behind
>> system time, i think this is the wrong point,
>> 'hwclock --utc --hctosys'
>> 'corrects' the system time exactly to rtc time,
>> thus repeatedly executing both commands will let you set back both
>> time values, what - posix or not, djb-way right or not - is definitely
>> not what anyone wants.
>
> This may not be what you want, but why aren't you using NTP to
> synchronize with the more accurate global clock services?

I started to reply, and I can't fully grasp what his point is (which
I admit may be because he's posting in English rather than his mother tongue).

I can't quite grasp why leapseconds would be an issue unless a computer is
sync'd to an atomic clock. Because I suspect most hardware clocks
will lose more time between leapseconds than the leapsecond will actually
add.

He's also made things compliacted, by dealing with something I suspect
most don't bother with (I didn't even know there was something about
configuring for leapseconds), without testing to see whether the problem
is there whether or not the system is setup for leapseconds. And surely
the issue isn't "dealing with leapseconds" since there haven't been any since
2005, but if there is a real problem, it's about that leapsecond
configuration. Take that away, and if the problem remains, the problem
lies elsewhere.

I don't keep my system constantly sync'd or even regularly sync'd. It's
been been a few weeks since I last connected with an atomic clock,
and I'm about 40 seconds off (compared to my standalone "atomic clock".
A leap second is not going to make any noticeable change on that. I notice
my hardware clock is actually more on time than the software clock.

Now, there may be an actual issue here, but it looks like leapseconds
have nothing to do with it.

Michael

hi group,

thks for fast answers,

sorry for my poor english,

@Nico Kadel-Garcia

>This may not be what you want, but why aren't you using NTP to
>synchronize with the more accurate global clock services?

exactly ... thats not what i asked for,
i am! on the way to introduce ntp clock sources, prefer the way from
djb, and this leaded into the described problem,

@Michael Black

> I started to reply, and I can't fully grasp what his point is (which
> I admit may be because he's posting in English rather than his mother tongue).

once more sorry for my poor english,

> I can't quite grasp why leapseconds would be an issue unless a computer is
> sync'd to an atomic clock. Because I suspect most hardware clocks
> will lose more time between leapseconds than the leapsecond will actually
> add.

it's ok, for you, when you can live with a system a little off from
time, but for other systems and users it's very important to have
accurate timestamps, so don't be astonished if someone asks for,

> He's also made things compliacted, by dealing with something I suspect
> most don't bother with (I didn't even know there was something about
> configuring for leapseconds), without testing to see whether the problem
> is there whether or not the system is setup for leapseconds. And surely
> the issue isn't "dealing with leapseconds" since there haven't been any since
> 2005, but if there is a real problem, it's about that leapsecond
> configuration. Take that away, and if the problem remains, the problem
> lies elsewhere.

i'm not intended to make things complicated, i'm just looking for a
reliable and complete solution, this must either correctly deal with
leapseconds, or ignore them leading to problems i.e. described in
http://cr.yp.to/proto/utctai.html.

> I don't keep my system constantly sync'd or even regularly sync'd. It's
> been been a few weeks since I last connected with an atomic clock,
> and I'm about 40 seconds off (compared to my standalone "atomic clock".
> A leap second is not going to make any noticeable change on that. I notice
> my hardware clock is actually more on time than the software clock.

in my particular case i'd like to have accurate timestamps for the
boot phase too, and cannot guarantee alltime ntp access, i'd dislike
to have the time 22 seconds off per default when ntp does not work
instantly after reboot,

> Now, there may be an actual issue here, but it looks like leapseconds
> have nothing to do with it.

for me it looks like a problem with leapseconds, not a problem of
leapseconds, just a problem how systems deal with them, in this
particular case that hwclock is dealing differently for the --systohc
and the --hctosys functionality,

> Michael

still helpless, :-)

[email protected] writes:

>pls. redirect if this group is wrong, couldn't find a better one in
>short time,

>searchwords: leap seconds timezone rtc cmos clock hwclock clockspeed
>date time

>problem: in short: hwclock seems to handle 'leapseconds' in a wrong
>way, leading to wrong time settings,

hwclock does not handle leapseconds at all.


>problem occurred on systems set up with 'right' zonefiles to use
>clockspeed, leap seconds and the 'djb-way', which are no longer
>'posix' conform,

No idea what the djb-way is. Maybe you need to tell us more?



>error occurring:
>'hwclock --utc --systohc'
>will set the rtc to a time something about 22 or 23 seconds behind
>system time, i think this is the wrong point,

hwclock should set the rtc to exactly what the system time is. tzinfo has
nothing to do with this. the zonefile is purely an interpretation between
the ststem clock and the time displayed on the screen.


>'hwclock --utc --hctosys'
>'corrects' the system time exactly to rtc time,

No, it does not correct. It simply copies the rtc time to the system time.


>thus repeatedly executing both commands will let you set back both
>time values, what - posix or not, djb-way right or not - is definitely
>not what anyone wants.

Agreed.


>problem on real systems: as many linux installations set system time
>from rtc on boot, and write back system time to rtc on shutdown,
>systems without external time correction will be off 22 more seconds
>with every reboot, and systems with external time correction
>(clockspeed, ntp, xntp, dfc77, ...) will be off for 22 seconds on boot
>(or any other value acc. to the rtc drift when you suppress the
>writeback on shutdown or on 'hard' shutoffs).

No idea what you are talking about. UTC is UTC, and has the leap seconds
factored in. Perhaps you mean GPS time of atomic clock time, but then GPS
time as reported by the receiver is actually UTC with the leap seconds
factored in.


>my idea where to search: i think hwclock uses different routines or
>system calls or options for the calculation of the time values, one
>respecting leap seconds, the other ignoring them, debugging this is
>far beyond my scope, so i'd like someone else to look for it,

>as far as the problem might be system specific: primergy tx 150 s5
>sata, sles 10 sp1 (suse linux enterprise server), both versions (32
>and 64 bit) mostly standard fresh installed system, changes to
>standard:
>ln -s /etc/localtime /usr/share/zoneinfo/right/Europe/Berlin,
>/etc/leapsecs.dat existing (don't know if from sles or install of
>clockspeed),

Why in the world would you be worrying about leapseconds?


>my idea is the problem is general and will show up on most systems an
>installations when you start using tai and leapseconds,

And you would do that why?


>procedure to reproduce: set up your system to work with leapseconds,
>mostly covered by the two steps above (google for djb, clockspeed and
>leapseconds for more info), then execute:
>date
>hwclock --systohc --utc
>hwclock --hctosys --utc
>date
>repeatedly, you can use a batch, and see if your system clock changes
>backwards.

>one possible but dirty workaround: use the 'wrong' standard zoneinfo
>files and kill the leapseconds info by renaming /etc/leapsecs.dat,
>really dirty, but i'll do until problem is solved,

No. Most things assume you use UTC, not Atomic time.


>pls don't complain this being a minor or exotic problem, which is
>overruled by use of external timesources, or suppressed by using
>'posix' standards, affecting only a short time in computer life
>(boot), one should not configure a system that way when no external
>time source is avaiable, djb being wrong, or things like this, it is!
>a malfunction, or at least something 'unusual', it wasted my time to
>check out, and it is good if someone can shed so much light on it that
>others do not do the some (waste time),

Well, yes, we might point out that this is minor and exotic problem, even
while we agree that hwclock should not act this way. Clearly under the
conditions you are using, hwclock is doing something weird. Look at the
source, and see where it is reading the leapsecond file.
So, one person in 1000000 who does something unusual could well uncover
bugs that noone else does.
But I am still puzzled by why you would use atomic time rather than UTC in
your system.



>a helpless user

>pls don't complain for missing full name, it's my privacy and
>complaining only wastes time,

[email protected] writes:

>hi group,

>thks for fast answers,

>sorry for my poor english,

>@Nico Kadel-Garcia

>>This may not be what you want, but why aren't you using NTP to
>>synchronize with the more accurate global clock services?

>exactly ... thats not what i asked for,
>i am! on the way to introduce ntp clock sources, prefer the way from
>djb, and this leaded into the described problem,

djb often does things weirdly, and that that weirdness can bite you is not
surprizing. Certainly if hwclock --utc --systohw ; hwclock --utc --hwtosys
leaves your system clock out by 23 sec over what it was before, that is a
bug. But unfortunately, since you are doing things really weirdly, it is
probably going to be up to you to find and fix the bug.



>@Michael Black

>> I started to reply, and I can't fully grasp what his point is (which
>> I admit may be because he's posting in English rather than his mother tongue).

>once more sorry for my poor english,

>> I can't quite grasp why leapseconds would be an issue unless a computer is
>> sync'd to an atomic clock. Because I suspect most hardware clocks
>> will lose more time between leapseconds than the leapsecond will actually
>> add.

>it's ok, for you, when you can live with a system a little off from
>time, but for other systems and users it's very important to have
>accurate timestamps, so don't be astonished if someone asks for,

Sure, ant most people want timestamps in UTC. and if you want accuracy then
you MUST sync to an external timestandard (eg GPS clocks) and that is
always done in UTC, not gps or atomic time. If you rely on your comptuter
clock your timestamps WILL be out, by far far more than any leapseconds.



>> He's also made things compliacted, by dealing with something I suspect
>> most don't bother with (I didn't even know there was something about
>> configuring for leapseconds), without testing to see whether the problem
>> is there whether or not the system is setup for leapseconds. And surely
>> the issue isn't "dealing with leapseconds" since there haven't been any since
>> 2005, but if there is a real problem, it's about that leapsecond
>> configuration. Take that away, and if the problem remains, the problem
>> lies elsewhere.

>i'm not intended to make things complicated, i'm just looking for a
>reliable and complete solution, this must either correctly deal with
>leapseconds, or ignore them leading to problems i.e. described in
>http://cr.yp.to/proto/utctai.html.

What problems?
Times on earth for almost everyone are in UTC. Yes, the difference in times
in UTC seconds needs correction for those infinitessimally small number of
people who care (eg astronomers). But then they know enough to know how to
handle it.



>> I don't keep my system constantly sync'd or even regularly sync'd. It's
>> been been a few weeks since I last connected with an atomic clock,
>> and I'm about 40 seconds off (compared to my standalone "atomic clock".
>> A leap second is not going to make any noticeable change on that. I notice
>> my hardware clock is actually more on time than the software clock.

>in my particular case i'd like to have accurate timestamps for the
>boot phase too, and cannot guarantee alltime ntp access, i'd dislike

Your hardware clock drifts from 1-10 sec/day. And since that is the only
source for times, it is impossible to get correct times in the bootup
phase.


>to have the time 22 seconds off per default when ntp does not work
>instantly after reboot,

Nonesense. If you would only stop trying tohave your system run on atomic
time, you will not have this problem. ( the rtc probelms will of course
still be there).


>> Now, there may be an actual issue here, but it looks like leapseconds
>> have nothing to do with it.

>for me it looks like a problem with leapseconds, not a problem of
>leapseconds, just a problem how systems deal with them, in this
>particular case that hwclock is dealing differently for the --systohc
>and the --hctosys functionality,

It is in the case that you want your system to run on atomit time rather
than utc. If you just let your system run on utc, everything is fine. If
you have to subtract times (Julian seconds) then you can correct for the
leapseconds. Since you do that far far far less often than you use the
clock for other things, that is where to do the correction.

hi group, thks for your contribution ...

but ... it happened according to my fears that we are
- discussing wether it's right to use tai, leapseconds and all that
stuff,
- discussing wether it's right to care for exact timestamps,
- discussing if djb is on the right way or 'weird',
and forget my request, i have a clear problem and i'm looking for a
solution,

i'd like to set up servers 'the djb way', at least try to, and solve
the problems which occur,
others would like to do it the suse, sles, posix or whatever way, for
me the arguments from
djb are clear and ok, and - as far as i am - his tools work very well,
so it's no need and no
benefit from arguing about these points,

googeling around i found some other people who tapped the some trap,
at least one wasting
weeks of time, but up to now no solution,

maybe - as often - there is a simple one i just don't see,

maybe someone - it's beyond my scope - can track down the functions of
hwclock and the
system calls it uses,

> bug. But unfortunately, since you are doing things really weirdly, it is
> probably going to be up to you to find and fix the bug.

it's not so weird, djb's arguments are clear, just do some research,
and plenty systems
do install 'right' timezone by default, commonly not using then, but
being prepared for later
recommendations

> Sure, ant most people want timestamps in UTC. and if you want accuracy then
> you MUST sync to an external timestandard (eg GPS clocks) and that is
> always done in UTC, not gps or atomic time. If you rely on your comptuter
> clock your timestamps WILL be out, by far far more than any leapseconds.

as i understand djb's clockspeed can handle utc and tai sources, thus
needs leapsec info
to convert into each other, the same challenge comes up for any other
software when the system
uses the 'right' - non posix - timezone files, guess why they are
named 'right',
and hwclock - as probably many other programs - fail in this
challenge, i think my timestamps are!
in utc, and i was! able to keep rtc and system clock accurate for less
than a second for many
years, just a new setup leaded me into the question how to deal in
future,

> >http://cr.yp.to/proto/utctai.html.
>
> What problems?
> Times on earth for almost everyone are in UTC. Yes, the difference in times
> in UTCsecondsneeds correction for those infinitessimally small number of
> people who care (eg astronomers). But then they know enough to know how to
> handle it.

problem that ... posix is incorrect, (x)ntp times unreliable, but most
people use it,

> Your hardware clock drifts from 1-10 sec/day. And since that is the only
> source for times, it is impossible to get correct times in the bootup
> phase.

i can correct most of this drift by hwclock --adjust, and i'm just
asking why in the world
i should add another 22 seconds to this drift, in other points we are
dealing with milliseconds,
the time from a timeserver is accurate for at least tenth of seconds,
why don't programmers
try to stay near these marks, it is a systematic bug, and those bugs
schould be solved rather than
covered with mayo,

> Nonesense. If you would only stop trying tohave your system run on atomic
> time, you will not have this problem. ( the rtc probelms will of course
> still be there).

nonsense is hard, just let's stop arguing if this is a good idea, for
me it would be nice to
have this problem solved, meanwhile i can live with the workaround
mentioned above,

> >particular case thathwclockis dealing differently for the --systohc
> >and the --hctosys functionality,
>
> It is in the case that you want your system to run on atomit time rather
> than utc. If you just let your system run on utc, everything is fine. If
> you have to subtract times (Julianseconds) then you can correct for the
> leapseconds. Since you do that far far far less often than you use the
> clock for other things, that is where to do the correction.

if it is - and bigger heads than mine have invested time and brain and
decided it is! - useful
to have a atomic (tai) time and convert other interpretations of time
from this exact source
then i'd like to be able to follow them, and i do learn a lot while
trying,

my way, i do not ask other people to follow,

still helpless,

hi group,

thks to all,

@all:
- pls. do not! contribute to this thread if you think a reliable time
basis and source is something neglectable,
- pls. do not! contribute to this thread if you think djb's ideas of
relying on tai is wrong,
- pls. do not! contribute to this thread if you think the systematic
fault of hwclock of misssetting the rtc can be corrected by --adjust,
- pls. do not! contribute to this thread if you think 23 seconds (or
22) are nothing to worry about,
- pls. do not! contribute to this thread if you mainly like to explain
how well you and your notebook work together,
- pls do not! contribute to this thread if you think i should fix
hwclock myself, i'm near an attempt to try, but have very little time
and very few skills in this direction, and explained this already,

all others, especially persons who have read djb's site and do work on
the same point / problem are sincerely invited to add to this
analysis,

@Old guy
> NOTE: Posting from groups.google.com (or some web-forums) dramatically
> reduces the chance of your post being seen. Find a real news server.

i'll try on the next problem, for the moment it's a decision between
keeping this thread and starting a new one,

> What distribution?

i'd write it, sles (SuSE Linux Enterprise Server) incl. the accurate
version, above, pls. check there, it (sles) does! set the system time
from rtc on bootup, and does! write it back on shutdown, but does do
the second in a wrong way with 22 or 23 seconds fault when configured
to use 'tai' and the 'right' zoneinfo file,

> boot time, network, timestamps,

as a fundumentalist - hi cia - i'd like to have correct times even if
network connection is broken, plausible?

> 22, 23 or 33 seconds,

the current utc - tai leap is 33 secs, 10 of them are already included
in the unix epoch (??? or something similar) so that on wrong gameplay
between different parts of a system 23 show up as gap, 22 on systems
who use old (from before 2005-01-01) leapsecs.dat files,

> hwclock with
> those two options does not introduce a _difference_ in the times

> Here, the RTC in trashbox7 is set to localtime (DST isn't used here).

thats plausible for me, i think 'my' differences come from the
calculations the system has do to between utc and localtime, your's
does not have to do those, localtime - afaik - is ok for people
without dst, others need utc to get automated switch to and from dst,

> What timezone are you using in the system

Europe/Berlin, but from the 'right' subdir, as explained above,

> (what does the shell variable TZ return,

how to check?

> or what does /etc/localtime point to,

at the moment: /usr/share/zoneinfo/Europe/Berlin, as i do it the
'dirty' way, the problems occur when it's pointed to /usr/share/
zoneinfo/right/Europe/Berlin

> or if all else fails, what does '/bin/date ; /bin/date -u' show)?

with the normal (wrong) zonefiles: cet and utc one hour apart, seconds
exact, what shall be normal for german winter,

with /usr/share/zoneinfo/right/Europe/Berlin nearly the same, but the
utc time being 23 seconds less than one hour behind cet, what's a
little confusing - isn't it?
concrete:
Fri Jan 4 19:48:00 CET 2008
Fri Jan 4 18:48:23 UTC 2008

@Unruh:

> He has gotten convinced by djb that everyone else in the world does things
wrongly

not everyone, but most people??

> and badly,

just a little,

> and wants to have his system on Bernstein time,

'Bernstein Time' is tai, invented some decades back as solution for
the urgent need of a stable monotone time base, try gps without or
trash satellites with other sources, your problem,

> rather than UTC with the zoneinfo files translating from Bernstein time to UTC.

it's not! only the need for exact time, it's also some
fundamentalistic mentality to want things to be solved in a clear and
accurate way, and to help others not to waste time in investigations
on the same problem again,

i hope this will be read by someone who can help,

helpless user,

[email protected] writes:

>hi group,

>thks to all,

>@all:
>- pls. do not! contribute to this thread if you think a reliable time
>basis and source is something neglectable,
>- pls. do not! contribute to this thread if you think djb's ideas of
>relying on tai is wrong,
>- pls. do not! contribute to this thread if you think the systematic
>fault of hwclock of misssetting the rtc can be corrected by --adjust,
>- pls. do not! contribute to this thread if you think 23 seconds (or
>22) are nothing to worry about,
>- pls. do not! contribute to this thread if you mainly like to explain
>how well you and your notebook work together,
>- pls do not! contribute to this thread if you think i should fix
>hwclock myself, i'm near an attempt to try, but have very little time
>and very few skills in this direction, and explained this already,

You might have noticed that this would have given you no answers
whatsoever. That is of course fine.


>all others, especially persons who have read djb's site and do work on
>the same point / problem are sincerely invited to add to this
>analysis,

>@Old guy
>> NOTE: Posting from groups.google.com (or some web-forums) dramatically
>> reduces the chance of your post being seen. Find a real news server.

>i'll try on the next problem, for the moment it's a decision between
>keeping this thread and starting a new one,

What has that got to do with posting from googlegroups. I use nn on my own
system, and reply to this group.


>> What distribution?

>i'd write it, sles (SuSE Linux Enterprise Server) incl. the accurate
>version, above, pls. check there, it (sles) does! set the system time
>from rtc on bootup, and does! write it back on shutdown, but does do
>the second in a wrong way with 22 or 23 seconds fault when configured
>to use 'tai' and the 'right' zoneinfo file,

>> boot time, network, timestamps,

>as a fundumentalist - hi cia - i'd like to have correct times even if
>network connection is broken, plausible?

The question os which right time. Most people call UTC ( with timezone
adjustments) the "right" time.


>> 22, 23 or 33 seconds,

>the current utc - tai leap is 33 secs, 10 of them are already included
>in the unix epoch (??? or something similar) so that on wrong gameplay
>between different parts of a system 23 show up as gap, 22 on systems
>who use old (from before 2005-01-01) leapsecs.dat files,

You are worried and use an old leapsecond file?



>> hwclock with
>> those two options does not introduce a _difference_ in the times

>> Here, the RTC in trashbox7 is set to localtime (DST isn't used here).

>thats plausible for me, i think 'my' differences come from the
>calculations the system has do to between utc and localtime, your's
>does not have to do those, localtime - afaik - is ok for people
>without dst, others need utc to get automated switch to and from dst,

What time is your rtc clock? I thought it WAS UTC. Is it actually
localtime.
Note that system time knowns nothing about local time.



>> What timezone are you using in the system

>Europe/Berlin, but from the 'right' subdir, as explained above,

>> (what does the shell variable TZ return,

>how to check?

>> or what does /etc/localtime point to,

>at the moment: /usr/share/zoneinfo/Europe/Berlin, as i do it the
>'dirty' way, the problems occur when it's pointed to /usr/share/
>zoneinfo/right/Europe/Berlin

Do not "point it" Copy the right file into /etc/localtime. That link may
not be up when the system boots and sets the system clock, and if it needs
info from /usr/share/zoneinfo, that info might not be there.



>> or if all else fails, what does '/bin/date ; /bin/date -u' show)?

>with the normal (wrong) zonefiles: cet and utc one hour apart, seconds
>exact, what shall be normal for german winter,

Why not post it.
And also what does
hwclock
show.



>with /usr/share/zoneinfo/right/Europe/Berlin nearly the same, but the
>utc time being 23 seconds less than one hour behind cet, what's a
>little confusing - isn't it?
>concrete:
>Fri Jan 4 19:48:00 CET 2008
>Fri Jan 4 18:48:23 UTC 2008

>@Unruh:

>> He has gotten convinced by djb that everyone else in the world does things
>wrongly

>not everyone, but most people??

>> and badly,

>just a little,

>> and wants to have his system on Bernstein time,

>'Bernstein Time' is tai, invented some decades back as solution for

No it is not. As has been pointed out, TAI is 33 sec, not 23 sec off from
UTC.


>the urgent need of a stable monotone time base, try gps without or
>trash satellites with other sources, your problem,

>> rather than UTC with the zoneinfo files translating from Bernstein time to UTC.

>it's not! only the need for exact time, it's also some

UTC IS exact time. It is not tai, but so what? It is just as exact as TAI
or Bernstein time. It is just different.
And the world uses UTC for timekeeping.

>fundamentalistic mentality to want things to be solved in a clear and
>accurate way, and to help others not to waste time in investigations
>on the same problem again,

>i hope this will be read by someone who can help,

We are trying. The fact that you have set ideas as to what constitutes help
does not help.

Is your rtc on localtime or on "UTC" . Look in your operating system files
to see which you tell it your rtc is on. If it is on utc, then as has been
pointed out hwclock does not behave as you claim it does. If it is on
localtime, then it may be that on bootup the leapseconds file or the
zoneinfo file are not available.


However, your requests are still weird. You demand that people give you
exactly the help you think you need, but do not want to pay anyone. If you
pay me $500/hr, plus airfare, I will come over and look into why your
system is misbehaving.




>helpless user,

([email protected]) writes:
> hi group,
>
But you're still missing the point.

An extra second, the leapsecond, added every few years means nothing,
because unless you are constantly resetting your hardware clock, the
accumulated error will be far greater.

Drop the leapsecond issue, drop all this other stuff that I've never
heard of, and deal with the hardware clock.

Until you simplify the problem, you will never be able to ascertain
where the problem lies.

Don't fuss with anything or make any adjustments, but just keep checking it
over weeks with
hwclock --show
Record the times, comparing it with a known good time. In other words,
tune your shortwave receiver to a time station (ie one that serves
only as a time and frequency standard), or get out your "atomic clock"
that syncs every night to data sent out by one of those time stations,
and see how much difference there is. The longer you keep this
up, the longer the difference will be.

Now you can deal with that problem in various ways. Get a computer or
clock board that keeps better time. Fuss with the actual clock oscillator,
adding temperature compensation or perhaps insulation to keep it at a
constant frequency. A crystal oven, to keep the crystal and even
the oscillator at a constant temperature even when the computer is off
will help things too.

Of course, some of the issue isn't how constant the oscillator in
the hardware clock is, but whether it's adjusted properly in the first
place. If it's not right on the frequency it needs to be, then it
will always be a slow or fast clock. You thus have to have an oscillator
that can be adjusted, and the skill and tools to adjust it. A really
precise frequency counter would be the easiest, but you have to have
one that is far better than the preciseness that you want from the
hardware clock. And you will have to measure, adjust, measure again
and adjust. If you don't have that frequency counter, it's a far
more tedious process, because you have to make an adjustment, keep
track of how far off it is (and that will take time, since the
closer you get the more time it takes to get an accumulated error
that will appear) and then adjust again, hoping you didn't go too
far in the wrong direction. Likely you'll need to change the
variable element in the clock's oscillator to something that is
multiturn, so you can make the needed fine adjustments.

Or, as someone suggested, if there is a trend in the drift, ie the
difference between the hardware clock and the time from the time
station is constant with time, then you can get your system to adjust
with software to compensate for that constant trend. This is similar
to the previous paragraph, except instead of adjusting the hardware,
you are telling the software that the clock's oscillator is off, and
by how much.

Or, you can sync the hardware clock with a time standard on the internet.

But until you deal with this, you'll never come close to "absolute time".
And leapseconds won't matter one bit, because you won't be able to tell
whether the one second addition every few years added for the leapsecond
is a leapsecond because it's lost in the accumulated seconds that come
from the drift of the hardware clock. Like I said, I can accumulate 20
seconds in a few weeks, if I kept that going for years one second would
be an insignificant thing, compared to the thousands of seconds that
come from the hardware clock being off.

The rise of "atomic clocks" around the household is precisly because
of all this. In the old days, you'd have a clock or two and maybe a watch
around the house. You'd set them and didn't care about absolute, since
nobody needed that precision. But as digital equipment took over, it
became so easy to add a clock function, they added them, causing massive
numbers of devices around the house with clocks. You still mostly don't
need precision, but it nags at you because every single clock is at a
different time. You no longer know which one was set exactly on time,
and have no idea which one is keeping proper time but with a constant
offset. So you buy yet another clock, one that receives the standard
time station and syncs to it. Instantly, you have a clock that you
can rely on, no fussing. You don't need the precision, you just
need to know that it has the "proper" time. You can set all the
others from it, and any variation you know is the other clocks.

Unless you can keep proper time in your computer, any talk of "precision"
or "standard" time means nothing, since even when you set the clock
right on time, chances are good it will not be "exact time" some time
later.

Michael