Messages in this thread | | | Date | Tue, 25 Jan 2000 15:43:02 +0100 | From | Guest section DW <> | Subject | Re: bug: wrong file times on ncpfs |
| |
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@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |