> For everybody who does not fiddle explicitly with this tz_dsttime field
> it is zero, so if the kernel uses it it makes no difference at all.
> Let us grep for tz_dsttime in 2.0.35:
Then explain why people with hour difference problems in SMB found they went
away when it was changed to use that.
Well, I would like to see such a person.
At present I do not believe she exists, unless she also wrotes
a private program including a call of settimeofday().
I am not aware of software that fiddles with this field.
On this machine here I have daylight saving time at present
but tz_dsttime is zero. (This is an unmodified RedHat 5.1 installation.)
Thus, although I sympathize with the idea that the kernel needs to know
whether we have daylight saving time now, it doesnt help to look at
sys_tz.tz_dsttime.
> Now you tell me that most people need a new meaning for this field?
I don't care what field they have. Irrespective of the correctness of the
current code or otherwise the kernel needs a function
is_daylightsavingstime()
because some protocols we talk network file dates to do so in local time
including daylight savings issues. These protocols are not bright designs
but we didnt design them.
Yes, reasonable enough.
But I object to the reuse of obsolete fields (with a new meaning).
It seems clear that the code to decide whether we have dst is far too
complicated to have in the kernel. So, a system call telling the
kernel about it would not be so bad.
Remains the question which program is going to contain that system call?
If you look at the code for the date utility:
int
stime (when)
time_t *when;
{
struct timeval tv;
tv.tv_sec = *when;
tv.tv_usec = 0;
return settimeofday (&tv, (struct timezone *) 0);
}
It does not use the struct timezone at all.
If you look at hwclock.c, it uses the semi-misguided code
tzset(); /* init timezone, daylight from TZ or ...zoneinfo/localtime */
const struct timezone tz = { timezone/60 - 60*daylight, 0 };
settimeofday(&tv, &tz);
that is, it sneaks the dst information into the tz_minuteswest field.
I'm all for patches to improve the situation
Then I propose that you remove these five references to tz_dsttime
(since they are wrong) and leave those to tz_minuteswest.
For people using hwclock (but not date) this might work out right.
Perhaps the person who wrote the patch in question has an opinion.
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/