FAT & Daylight Savings Time Error

FAT & Daylight Savings Time Error

Post by Jeffrey Sassinsk » Mon, 02 Sep 2002 01:39:17



All right, maybe this has been addressed.  In fact, I can't see how it
hasn't been addressed, but I've been looking for days and can't find a fix.

It seems that FAT (MSDOS, FAT & VFAT) screws up when converting times to
UNIX time (aka UTC) and then back to local time.  It doesn't take into
account Daylight Savings Time.  Actually, it does, but not correctly.

Here's the issue as I see it.  The FAT file system on Windows stores all
dates and times as local time.  Whatever time the system clock has
(whether it is EST or EDT or MST or whatever) that gets written to the
drive.

When mounting a FAT partition under Linux, it converts all of these
times to  UTC using the value of sys_tz.tz_minuteswest.  But, here's the
issue.  There is another value in the kernel called
sys_tz.tz_daylightsavings, but this doesn't seem to be used anymore.
What happens is, tz_daylightsavings gets changed according to the
"effective time zone" taking into account daylight savings time.

For example, EST is -5 hours from UTC, but EDT is -4 hours from UTC.
So, during daylight savings time, tz_minuteswest is 4*60 and during
standard time it is 5*60.

This is applied to the FAT dates to bring them to UTC, but if
tz_minuteswest is set to 4*60 during daylight savings time, then only
files written during daylight savings time are correctly being moved to
UTC.  Files written during standard time are 1 hour less than they
should be.  The reverse is true when the Linux box is set to standard
time.  There, files written during daylight savings time are one hour
more than they should be.

Now the Linux box "thinks" that all times on the FAT file system are
correctly moved to UTC even though they are not.  So when it displays
them, it coverts back to local time.  However, it takes into account the
date of the file, and brings them to local time using the correct offset
according to the file date.  If the file date is during standard time
(in the East), it subtracts 5 hours, if the date is during daylight
savings time, it subtracts 4 hours.  But, half of the files have not
been correctly brought to UTC, so half of the files are 1 hour off.  If
the Linux box is correctly in daylight savings time, all files on the
FAT file system written during DST are correct and all standard time
files are wrong.  Vice versa if the Linux box is in standard time.

Is there a patch out there?  I find it hard to believe that this has
never been addressed, but in searching the news groups it looks like it
has come up, but has never been fixed.

Any ideas?

Thanks...

 
 
 

1. Daylight Savings time, system time, hardware time....

I am sure that this has been rehashed a bunch of times, but I can't seem
to get it through my thick  skull...

I have a RedHat 6.0 system, 2.2.13 kernel.  I need to configure the darn
thing to keep the right time.  I can't seem to correctly configure the
hardware clock so that it correctly deals with DST.

I tried setting it to UTC using RedHat's tools, but it had no effect.
The time zone information must be correct, since the calendar displays
EDT, but the hardware clock and the system clock are now exactly
backwards.....  The hardware clock is one hour ahead of the system
clock.


Wed Apr 19 13:48:25 EDT 2000
Wed Apr 19 14:48:26 2000  -0.940635 seconds

What files do I need to change (by hand, not through possibly broken GUI
tools) to make this right?

Thanks,

--Yan
--

Think different
        ride a recumbent
                use Linux.

2. How do I access Windows Printers & Files

3. Daylight Savings Time & linux 1.0 ?

4. hostname

5. Exact time for Daylight Savings Time change

6. Slack2.0(k1.0.9) XFree2.1: Xconsole cannot open console?

7. Olympic Daylight Savings Time...

8. Linux on second IDE?!

9. daylight savings time?

10. Linux Time setup - Daylight savings

11. Daylight savings time - setup

12. How to set daylight savings time in Linux?

13. daylight savings time...