Re: hwclock problem with leapseconds - posix?

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,
- 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,
- 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,
and one would expect 'hwclock -- systohc; hwclock --hctosys' to keep
system time correct not changing it,
- this should happen regardless of the applied timezone settings, an
it does fail with 'leapsecond respecting time zones',
- this is a design failure either in kernel, kernel routines, the
utilities, the timezone files ore wherever, i cannot, can please
someone solve this?

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
hwclock and date functioning reliable, and!!! being able to use
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,
- 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,
- 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,
- when using a timeserver, clockctl and the 'leap second respecting'
timezones my system is fine, my time exact enough for ebay, ok,
- 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,
- 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,

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',

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'
- 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,

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, :-)
- why not respect their ideas?

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,

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,
- it is not!!! my problem to get a correct time value from the net
using bernsteins programs,
- 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,

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,

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
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?
    ... preferably i also want the rtc updated during normal running system, ... You are using modified TAI, ... I have no idea what a leapsecond respecting timezone is. ... served better by using UTC. ...
    (comp.os.linux.setup)
  • 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?
    ... 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: What time is it? Issues with Local time, system time, DST
    ... Apparently CE stores time in local time, ... be for local time, not UTC. ... RTC, so that when processor is asleep or off, onboard batteries ... you can't know the UTC unless you also have, in some non-volatile ...
    (microsoft.public.windowsce.platbuilder)
  • Re: SCO 5.0.5/5.0.6 bios clock, time zone and synching
    ... >Does SCO expect the BIOS clock to be set to UTC? ... All versions of SCO OpenServer and the OSes that led up to it (including ... all versions of SCO XENIX) expect the RTC ...
    (comp.unix.sco.misc)
Loading