Re: hwclock problem with leapseconds - posix?

cc-tec@xxxxxx writes:

hi folks,

off from the flames, back to the problem, thanks,

i'll try to bring in what i'm able to,

sorry for not naming quotes,

SuSE writing to the RTC on shutdown is a function of the system
shutdown scripts. You may find it useful to look through those, and
either disable the action, or give it the "right" options (what-ever
they may be).

right, but
- i want system time stored in rtc on shutdown,
- preferably i also want the rtc updated during normal running system,
being able to calculate it's drift and use the correction factor on
boot,

Then use chrony, not ntp. Without an outside time source how in the world
do you know what the drift is?

Note could you please post the contents of /etc/adjtime


- either the system does or me doing manually, some system functions
misinterpret system time, substract leap seconds or forget to add or
whatever, and write a wrong - 23 seconds off - time to the rtc, on
startup this misinterpretation is left off, or does happen here and
not on shutdown, ????, resulting the system time set from rtc on
startup is 23 seconds off,

Sorry but I do not believe this. There is nothing in hwclock that reads the
time, or the leapseconds that I can see.


- the problem looks more general, normally one would expect 'date' and
'date -u' to show something exact one hour different in Germany, two
hours during DST, but not UTC being 59 minutes, 37 seconds behind CET,

You are not using DST. You are using modified TAI, what I called Bernstein
time (UTC=Bernstein at epoch)

and one would expect 'hwclock -- systohc; hwclock --hctosys' to keep
system time correct not changing it,

Look at /etc/adjtime file-- post the output.

- this should happen regardless of the applied timezone settings, an
it does fail with 'leapsecond respecting time zones',

I have no idea what a leapsecond respecting timezone is. I suspect it is a
timezone which subtracts 23 sec

- this is a design failure either in kernel, kernel routines, the
utilities, the timezone files ore wherever, i cannot, can please
someone solve this?

Again, why in the world should we solve it? We are not concerned. The
solution will have to come from you.



What is "correct"? If you are doing astronomical tasks, then I can
see setting the system to TAI - but all other tasks would likely be
served better by using UTC. Again, if you really need accurate time,
then you shouldn't be using the computer times until they have been
set
synchronized to an accurate time server of some appropriate kind.

- philosophical question, for me it would be fine having routines like

YOU are the one who is raising it. You are the one who is using a
non-standard time, and refuses to use what everyone else does.

hwclock and date functioning reliable, and!!! being able to use

They are. Millions use them without trouble.

programs that 'correctly' ;-) deal with leap seconds on the same
system, up from that point it's my responibility what time i set or
what i store in rtc,

It is this last that is YOUR responsibility. I am not going to put my
system onto Bernstein time just to solve your problem


- as far as i understand i do not set the system to tai, or only parts
of it, but just tell it to respect leap seconds on time conversion
routines, this resulting in misbehaving some system utilities,

No idea what that means, unless it means "subtract 23 sec from every time
and post that".


- there are different time 'lines', basically tai, linux 'epoch'
started on 1970-01-01 0:0:0, utc epoch started in 1960's, synced to
TAI on 1972-01-01 0:0:0, (just which 'zero'? tai? gmt?), utc with
regional deviation added cet and others, with DST added even more
which are not monotone, UT (Universal Time) the value stored in RTC, a
clock in the CPU, the 'kernel time / kernel clock' (some as the CPU?)
and the values the OS is presenting me on screen, syncing and
converting them is quite a big deal, and byond my scope to check all
this out,

Well, you are the one who got himself into this mess by deciding to use
non-standard time.
Note that there are only two issues. One, the kernel time is unsynchronized
uniform seconds. Ie, it keeps ticking one second after the other. Unfotunately
it is not sychronized to anything and its second is not the time standard
definition of the second. NTP, which you claim not to use, uses UTC.
This means that its rate is the "true " second. Since it is UTC, it throws
away leap seconds, and assumes that each day of the year has 60*60*24
seconds, and thus the seconds since epoch reported by the system is not the
number of seconds which have actually occured since epoch.


- when using a timeserver, clockctl and the 'leap second respecting'
timezones my system is fine, my time exact enough for ebay, ok,

If you want your times for ebay, use UTC, and be done with it.


- just when storing system time in RTC and getting it back from there
it's changed, and when i call date -u i'm presented a wrong UTC time
(or is this correct and the date value for CET wrong?), thats nasty,

You are the one that wants to use a non-standard time.


- if it's not possible to find the fault and correct it i have to
switch back to posix timezone files, or do other dirty workarounds,
but i'd prefer the central error being found and eliminated,

Then do it.



That has absolutely nothing to do with the timezone the RTC is using.

- afaik RTC stores only a value, no information on timezones, DST or
other things, it's the responsibility of the OS what it doe's with
this value, for a reliable OS all routines must deal with this value
in the some way, it looks like linux doesn't when using olson
('right') timezones, this must either be corrected by olson, djb, or
linus or the maintainers of the system utilities, my idea is that a
system being able to deal with leap seconds is more reliable than one
ignoring them, so i'm asking for a solution from this side, maybe
there are solutions like -TAI instead -UTC for RTC info, using a
different set of utilities, ???, whatever, i'd like someone show me a
solution other then 'go back tp posix',

If you think that the maintainers of linux will rewrite their routines for
you to use your TAI you are in a dream world. They have much more urgent
things to get working in Linux than to concern themselves with something
that one person in 10,000 uses.


The problem is that "right" directory. Few use it, because it differs from what everyone else is using.

- yeah, but those few are 'right' in the idea to teach their system
the real conversion between tai and utc enabling it to use tai instead
of xntpd? for time syncing, avoiding conversion faults - in very
seldom moments -, just to have something 'correct'

It is no more correct than is the standard, as I have pointed out many
times. UTC is a well accepted and respected time standard. The decision
was to use utc, not tai. David Mills of ntp has stated that he has had
numerous discussions as to whether UTC should be used for ntp, precisely
for the concerns you have, and has come to the conclusion that it should be.



- if a system (SuSE, Linux, ...) can deal with it (the 'right'
directory), it should do it correctly, if it cannot it - the directory
- shouldn't be there, funnywise it's part of at least one big linux
distribution, and that for many years now,

Talk to the SUSE people. Or erase the directory from your system.


Anyone who may send me a report about network activities would be
using either
UTC or their local time zone.

- ok, that's a real world challenge, when checking log files from
different systems it's a good point when they have been on the same
time, so we agree in the need,
- xntp(d?) and posix have some - little - problems to deal with time,
so some - few - people want to use something more reliable, thats
progress, :-)

They have no problem whatsoever. What they use is ultra reliable. What you
have is a little bit of knowledge which is a dangerous thing.


- why not respect their ideas?

Go ahead. Noone is stopping you. It is when you demand that others solve
for you the problems that your running after those pied pipers creates that
you run into resistance.


I postulated that his problem with the 22 or 23 second offset is caused by
his using a "local" timezone, which uses his "right" zoneinfo files,
but
screws up the determination of the leapsecond offset, or at least does
so
differently on bootup from shutdown.

correct,
- it also does it for read and write the rtc with hwclock, and for the
time interpretation of 'date -u' and possibly some other routines,

No, it does not, as we have stated. hwclock works fine on our systems.


I was the one who gave the name to what he uses as "Bernstein time" given
that it is NOT TAI, since it only takes account of the 23 seconds
difference due to leapseconds since 1970 not the full 33 sec used in
the
definition of TAI. Ie, He is using the epoch of Jan 1 0:0:0 1970 in
UTC in
the definition of his time, but then using the TAI difference in
seconds
from that time. I pejoratively used the name Bernstein time to refer
to
this combination.

- 'pejoratively', funny word, will look it up later,
- UTC has a 'start offset' of +10 to TAI on 1972-01-01 0:0:0, now UTC
is TAI +33 seconds, 10 seconds are already in the 'wrong' zonefiles?,
so nowadays handling leap seconds is to add 23 to an tai announced
time?? thats what Bernstein does, clear and 'right' for me, besides -
but unimportant in throwing stones - he doesn't do this totally on his
own but uses 'things' normal systems offer, 'right' timezones and
leapsecs.dat files to correct the deviation, just the systems do funny
things - on their own - when using them,

No. He and Olson use an unofficial time standard. It is not tai-- it is 10
sec out from tai. It is not utc. It is not recognized by any standards body
in the world. It is a complete abortion. Had they been honest and used TAI
one might think they had a case, a weak one, but a case.


- it is not!!! my problem to get a correct time value from the net
using bernsteins programs,

Yes, it is your problem.

- it is the only!!! problem to get my system set and read the RTC
correctly when using 'right' timezone files,



... other funny things ... Of course non of this explains his observation that that hctosys and
systohc has a hysteresis of 22 or 23 sec when he uses his calendar.

- yeah, lets just stick to
that, !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
and it has!!!, re- re- and rechecked, documented above, and later on
rechecked over boot cycles with ntp synchronisation off,

Look at /etc/adjtime



In any case, since all the "times" discussed here use TAI seconds they
could be viewed as merely different ways of labeling the stream of TAI
seconds.

- yes, and a system that in one conversion adds 23 seconds - to get
UTC, should subtract them on re-conversion, and everything would bee
fine,

... some calculations ...

- will check them and answer later,

Ie, one way true seconds since epoch was used and the other way utc sec
since epoch were used, which he regarded as a bug, which it certainly
is.
The question is --where is the bug. He wants "us" to find it.

- thks, thats been a long way to this point,
- 'he wants "us"' ... thats the way i understand the world / the
usenet / the internet / the linux community / ... everyone gives the
help he or she can, ... i do not personally ask 'you' but the whole
outside world, all persons interested, because it can be useful for
plenty more people than me to get this issue solved,
- i am a little better in finding bugs than solving, but there is a
need for people like me in the world,

Actually, no. It is like skiers who go outside the boundaries of the ski
hill and then expect the rest of the world to come searching for them when
they get into trouble. It is not clear that people like that are needed.



As I understand the concept of leap seconds no hardware clock can possibly deal
with them. They are the produce of 1 part per 365.25x24x60x60
variations in a
year. They can go plus, minus and can be changed by tectonic events.
Solar time
is meaningless in the real world. If you need that kind of accuracy
you will
have to buy your own clock, cesium, rubidium, or whatever they are
using these days.

- yes, that's right, as mentioned above the RTC runs without leap
seconds and just timezone or DST info, the problem is the misbehaving
in the program hwclock which is used to read and write the hardware
clock (RTC), and of other programs,
- i repeat: i do not need absolute accuracy, i need correct
interpretation for the accurate time i can get from time servers, and

ntp give you utc. They probably will not change.


i need a way to store a value in the RTC which is stored and reread
with the same - ok opposite - calculation to avoid a 23 second bug,

- if anyone needs another approach to the problem, check that your
system has a /etc/leapsecs.dat file, execute
'ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime; date +%s;
date -u +%s; date; date -u'
funny, value for seconds is identic, date differs, by one hour, thats
correct,
and explain why
'ln -sf /usr/share/zoneinfo/right/Europe/Berlin /etc/localtime; date +
%s; date -u +%s; date; date -u'
gives 23 second less than an hour difference between CET and UTC,

my - for the moment - interpretation: for calculating utc times 'date'
does respect leapseconds.dat file, for cet calculations it's ignored,
either may be right, the other must! be wrong, leap seconds are
global,

i'll check in detail later these days,

helpless user
.

Relevant Pages

  • Re: hwclock problem with leapseconds - posix?
    ... a quick look shows that hwclock uses the routines mktime with the timezone ... I suspect that the assumption that we are using UTC, not TAI, and that the ... preferably i also want the rtc updated during normal running system, ...
    (comp.os.linux.setup)
  • Re: hwclock problem with leapseconds - posix?
    ... preferably i also want the rtc updated during normal running system, ... utilities, the timezone files ore wherever, i cannot, can please ... served better by using UTC. ... as far as i understand i do not set the system to tai, ...
    (comp.os.linux.setup)
  • Re: hwclock problem with leapseconds - posix?
    ... fault of hwclock of misssetting the rtc can be corrected by --adjust, ... to use 'tai' and the 'right' zoneinfo file, ... Most people call UTC (with timezone ... calculations the system has do to between utc and localtime, ...
    (comp.os.linux.setup)
  • Re: Requiring a date be entered as mm/dd/yy on a form field.
    ... specify that they cannot calculate to that precision. ... Furthermore, UTC ... use whatever standard they are given. ... Most areas have some name that they use to refer to their timezone. ...
    (microsoft.public.scripting.jscript)
  • Re: hwclock problem with leapseconds - posix? - solved?
    ... dealing with tai or something like that - look into the thread ... internal calculations (at least the utc one when referring to utc ... their own" calculation of UTC from seconds since epoch. ... Linux epoch. ...
    (comp.os.linux.setup)