My problems got bigger with that change. Modification times on my FAT
partition are now off by two ours rather than only one. This is
because I run the CMOS clock in UTC instead of local time. I think
there must be a mount option to really fix the problem.
> 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.
Yep.
What I'm wondering about is if the kernel already handles a transition
from DST to non-DST in a sane way. The kernel would have to use a
different local time - UTC offset after the transition.
Use an user mode daemon that updates the offset when the transition
happens? Hmm. No. Imperfect. There would always be a (small) time
window with the wrong offset.
Teach the kernel everything about time handling to do that without any
user mode stuff? Would be really dirty kernel bloat.
The best solution I can think of is: Use a user mode daemon (well,
cron job is probably better) that tells the kernel something like
"at time 901234567 change offset to 3600, at time 904567890 change
offset to 7200". This list in kernel space should be updated once in a
while by a cron job to incorporate time zone definition changes and
leap seconds (provided /usr/lib/zoneinfo is kept up-to-date).
-- Jan- 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/