On Mon 12-11-12 01:06:41, OGAWA Hirofumi wrote: > Jan Kara <jack@xxxxxxx> writes: > > > So far FAT either offsets time stamps by sys_tz.minuteswest or leaves them > > as they are (when tz=UTC mount option is used). However in some cases it > > is useful if one can specify time stamp offset on his own (e.g. when time > > zone of the camera connected is different from time zone of the computer, > > or when HW clock is in UTC and thus sys_tz.minuteswest == 0). > > > > So provide a mount option tz= which allows user to specify offset in minutes > > that should be applied to time stamps on the filesystem. > > What is in some cases? tz_minuteswest style timezone is known as it > doesn't work. E.g. summer time. Yes, DST is one problem. Another problem (which is more annoying to the user reporting this) is that he has HW clock set to UTC but system time is in CET. Somewhat surprisingly (at least to me before I read the code) this means sys_tz.minuteswest == 0. So when he connects say his camera, which has time in CET, to the computer he sees timestamps off by one hour. With tz= mount option he could mount the filesystem with tz=60 and be mostly happy (modulo DST). > And tz= is reserved for true solution. E.g. load timezone database to > kernel and use it for time conversion. So, if we really want this hack, > it should be different option name. Yes, knowing about time zones in kernel is the only way to properly handle fat timestamps in the presence of DST. But time zones are such a mess (DST being determined by a law separately each year) I don't see this happening - the annoyance by bad timestamps simply isn't big enough. If you feel strongly about reserving 'tz' mount option, I can rename the mount option to something else... Would 'time_offset' be OK with you? Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
