bug: wrong file times on ncpfs

[Guest section DW]

On Tue, Jan 25, 2000 at 09:58:57AM +0300, Oleg Makarenko wrote:

> The problem: All file times on Novell server are one hour older then
> they really are. (RH6.x,no matter what 2.2 kernel. The timezone settings
> do really matter and the time is wrong for any timezone that has DST but
> DST is NOT active)

Yes.

Several years ago I wrote in settimeofday.2:

       The use of the timezone struct is obsolete; the tz_dsttime
       field has never been used under Linux - it  has  not  been
       and  will  not  be  supported  by libc or glibc.  Each and
       every occurrence of this field in the kernel source (other
       than  the  declaration)  is  a bug. Thus, the following is
       purely of historic interest.

       The field tz_dsttime contains a symbolic constant  (values
       are  given below) that indicates in which part of the year
       stant  throughout the year - it does not indicate that DST
       is in force, it just selects an algorithm.)

The author of hwclock didnt believe me and tried to use "daylight"
anyway, as if it indicated that DST is in force now. But it doesnt,
so this fails. Since I maintain hwclock these days, I removed this
code from hwclock 2.10e as released a few days ago.

Similarly, many kernel authors are deluded and one finds
	./linux/fs/fat/misc.c:  if (sys_tz.tz_dsttime) secs -= 3600;
	./linux/fs/fat/misc.c:  if (sys_tz.tz_dsttime) unix_date += 3600;
	./linux/fs/hpfs/hpfs_fn.h:      return t + sys_tz.tz_minuteswest * 60
		- (sys_tz.tz_dsttime ? 3600 : 0) + ...
	./linux/fs/udf/udftime.c:       offset = (-sys_tz.tz_minuteswest
		+ (sys_tz.tz_dsttime ? 60 : 0));
as if tz_dsttime indicated that DST is in force now.
All these occurrences are bugs, and life is simplified when every
fragment like `+ (sys_tz.tz_dsttime ? 60 : 0)' is deleted from
kernel source. Maybe I should construct a patch.

[The hfs author does the right thing in hfs_sysdep.h]

Does this solve all problems? No - I think it is impossible to solve
this problem in the kernel. If timestamps on some filesystems are
in localtime, and the kernel does not have all of Olsens timezone
code, then it cannot convert this to UTC and back. (And close to the
moment of change this isnt even a 1-1 function. So, mirror software
will always have difficulties close to the change of DST if the
filesystem uses localtime.)

The problem comes up every now and then; some months ago there was
an extensive discussion. I mainly answer now to make people aware
of the fact that the hwclock behaviour changed. Some incorrect code
was removed. I may well be convinced to add some correct code instead,
adapting tz_minuteswest under suitable circumstances.

Andries



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/