Kunihiko IMAI wrote:

Hello Kunihiko,

Elsewhere in the man page it says:

       Under Linux there are some peculiar "warp  clock"  seman-
       tics associated with the settimeofday() system call if on
       the very first call (after booting) that has  a  non-NULL
       tz  argument,  the  tv  argument  is NULL and the tz_min-
       uteswest field is nonzero.  In such a case it is  assumed
       that  the CMOS clock is on local time, and that it has to
       be incremented by this amount to get UTC system time.  No
       doubt it is a bad idea to use this feature.

This seems to cover the point you are describing.  Do you still think some
change is required?

Cheers,

Michael

Hello Michael and mantainers,

Michael Kerrisk wrote:

Hmm....  Is this enough description?  For example, to write 'date' or
'hwclock' from full scratch.

I sure that it is good at some computers that have localtime RTCs.
Imagine a computer which has a UTC RTC.  What sequence of settimeofday()
we should make at the early boot time?  We don't have to set tz?

I think, for the best way of understanding tz, describe like that:

	MS-DOS and some non-native filesystems use tz.minuteswest for
	adjusting timestamps.  You must set tz.minuteswest at least once
	from the boottime before using those filesystems.

	( I wish someone rewrite this more natural description.  I am
	a non-native English user. )

Hiding this fact makes this manual misleadable.



By the way, I think that we don't have to describe on the manual about
unobservable thing from userspace, for example, 'jiffies' kernel
valiable.  But this timestamp adjusting feature is observable to do as
follows:

1. do settimeofday() with tz.minuteswest = -540 (Japanese Standard Time;
or your localtime.)

2. mount a MS-DOS floppy and do 'ls -l'.

3. umount the floppy.

4. do settimeofday() with tz.minuteswest = 0 (UTC)

5. again, mount the same MS-DOS floopy and do 'ls -l'.




Thanks.

Kunihiko IMAI