hwclock problem with leapseconds - posix?

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

Relevant Pages

  • Re: hwclock problem with leapseconds - posix?
    ... hwclock should set the rtc to exactly what the system time is. ... and has the leap seconds ... Why in the world would you be worrying about leapseconds? ...
    (comp.os.linux.setup)
  • Re: hwclock problem with leapseconds - posix?
    ... leap seconds timezone rtc cmos clock hwclock clockspeed ... Agreed that leapseconds cannot be predicted arbitrarily far into the ... writing to rtc differently from reading from rtc. ...
    (comp.os.linux.setup)
  • Re: hwclock problem with leapseconds - posix?
    ... will set the rtc to a time something about 22 or 23 seconds behind ... systems without external time correction will be off 22 more seconds ... /etc/leapsecs.dat existing (don't know if from sles or install of ... installations when you start using tai and leapseconds, ...
    (comp.os.linux.setup)
  • Re: hwclock problem with leapseconds - posix?
    ... leap seconds timezone rtc cmos clock hwclock clockspeed ... I can't quite grasp why leapseconds would be an issue unless a computer is ...
    (comp.os.linux.setup)
  • Re: Linux 11-minute mode (RTC update)
    ... Depending on the mode of operation, hwclock consumes either much more, ... OTOH its drift compensation allows sparser ... Note that the advantage of recording the rate as well as offset of the rtc ... Example an RTC with a 100 PPM drift rate. ...
    (comp.protocols.time.ntp)