Re: hwclock problem with leapseconds - posix?

On Tue, 1 Jan 2008, in the Usenet newsgroup comp.os.linux.setup, in article
<7321c5fa-4933-423d-99cb-fe0d71aef9ec@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
cc-tec@xxxxxx wrote:

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

in my particular case i'd like to have accurate timestamps for the
boot phase too

What distribution? Most systems set the "software" clock in the
first boot script. Assuming your system uses /etc/inittab (most do),
look at the 'System initialization' script

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

in this case 'rc.sysinit' and you'll find it starting the clock there.
HOWEVER, nothing gets written to the logs until the end of that script
where you may find something like

# Now that we have all of our basic modules loaded and the kernel going,
# let's dump the syslog ring somewhere so we can find it later
dmesg > /var/log/dmesg

and the only 'time' information there is the file timestamp. The logging
daemon isn't started until later in the boot cycle, such as

/etc/rc.d/rc3.d/S30syslog

which MAY be after networking is brought up

/etc/rc.d/rc3.d/S10network

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,

I've no idea where you are finding a 22 second difference, as the current
difference between UTC and TAI is 33 seconds (see

# Paris, 28 June 2007
#
# Bulletin C 34

# INFORMATION ON UTC - TAI
#
# NO positive leap second will be introduced at the end of December 2007.
# The difference between Coordinated Universal Time UTC and the
# International Atomic Time TAI is :
#
# from 2006 January 1, 0h UTC, until further notice : UTC-TAI = -33 s

which is in the file 'leapseconds' in the tzdata2007k.tar.gz tarball
you can get from ftp://elsie.nci.nih.gov/pub/ )

-rw-r--r-- 1 8800 0 163688 Dec 31 15:25 tzdata2007k.tar.gz

[COMMENT: 2007j -> 2007k changes a link for Atlantic/Jan_Mayen and
institutes DST for Argentina beginning a day prior to the tarball date.]

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,

I'm not sure why you are having a problem, as running hwclock with
those two options does not introduce a _difference_ in the times.

[trashbox7 /]# /sbin/hwclock --show ; /bin/date
Wed Jan 2 12:34:52 2008 -0.205553 seconds
Wed Jan 2 12:34:52 MST 2008
[trashbox7 /]# /sbin/hwclock --systohc
[trashbox7 /]# /sbin/hwclock --show ; /bin/date
Wed Jan 2 12:35:01 2008 -0.194958 seconds
Wed Jan 2 12:35:01 MST 2008
[trashbox7 /]# /sbin/hwclock --hctosys
[trashbox7 /]# /sbin/hwclock --show ; /bin/date
Wed Jan 2 12:35:09 2008 -0.280010 seconds
Wed Jan 2 12:35:09 MST 2008
[trashbox7 /]

Here, the RTC in trashbox7 is set to localtime (DST isn't used here).
What timezone are you using in the system (what does the shell variable
TZ return, or what does /etc/localtime point to, or if all else fails,
what does '/bin/date ; /bin/date -u' show)?

Old guy
.

Relevant Pages