lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 09 Nov 2009 00:48:33 +0900
From:	OGAWA Hirofumi <>
To:	Paolo Giarrusso <>
Subject: Re: Daylight saving time & FAT

Paolo Giarrusso <> writes:

> When re-rsync'ing two hard drives (one VFAT, one NTFS mounted with
> ntfs-3g) after a Daylight Saving Time change (I was on CEST, +0200,
> now I'm on CET, +0100), I discovered a one-hour time difference over
> all files (on FAT, they are one hour in future).
> My current understanding is that FAT stores times relative to the
> current timezone, and that's crappy (see fat_time_fat2unix(), in
> fs/fat/misc.c). But with the current code, it gets even more crappy -
> the same file will have a different _UTC_ timestamp depending on my
> current timezone, since the current offset from UTC is added to the
> stored timestamp to get the UTC time (I verified the timezone change
> would perfectly explain, even in sign, the time difference I found).
> That's why I guess that the FAT timestamps are wrong.
> I frankly doubt that Windows is so bad.
> On DOS, they could get away without any conversion at all. But on
> current Windows systems? Either you find the right time zone at file
> saving time (too complicated IMHO) or ignore DST when saving/restoring
> time (i.e. pretend DST is not in effect, and add the shift if needed).
> I don't know right now what happens.
> I wrote this mail to discuss what would be the correct solution (the
> second?), and if it is possible to implement it.

fat_time_{fat2unix,unix2fat}() doesn't handle timezone correctly. It
just uses timeoffset from sys_tz.tz_minuteswest. But, it is not enough
for localtime. Because it doesn't handle DST or such complex stuff. (As
workaround, fat has "tz=UTC" option)

To get correct conversion, those functions have to handle timezone
database (zoneinfo or something).

I think the issues would be, who (userland or kernel) handle zoneinfo,
and how handle.

Well, so, FWIW, I was thinking make timezone subsystem. userland app
pass one of zoneinfo to kernel as data via ioctl or sysfs or something
with name, and subsystem manages the lifetime/etc. of data.  And
provide utc2local(time, zone name) to convert time correctly.

So, fs would be able to get help of utc2local() to convert to on-disk
format, and probably, zonename will be specified as mount option.

OGAWA Hirofumi <>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists