This is a discussion on Re: hwclock problem with leapseconds - posix? - Setup ; firstname.lastname@example.org 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, ...
>pls. redirect if this group is wrong, couldn't find a better one in
>searchwords: leap seconds timezone rtc cmos clock hwclock clockspeed
>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
No idea what the djb-way is. Maybe you need to tell us more?
>'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.
>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
>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
>ln -s /etc/localtime /usr/share/zoneinfo/right/Europe/Berlin,
>/etc/leapsecs.dat existing (don't know if from sles or install of
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:
>hwclock --systohc --utc
>hwclock --hctosys --utc
>repeatedly, you can use a batch, and see if your system clock changes
>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
>a helpless user
>pls don't complain for missing full name, it's my privacy and
>complaining only wastes time,