Bug 556979 - bad time zone in FAT partitions (sys_tz is not set by hwclock)
Summary: bad time zone in FAT partitions (sys_tz is not set by hwclock)
Status: RESOLVED FIXED
Alias: None
Product: openSUSE 11.2
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Final
Hardware: Other Other
: P4 - Low : Minor (vote)
Target Milestone: ---
Assignee: Petr Uzel
QA Contact: E-mail List
URL:
Whiteboard: util-linux
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-19 17:53 UTC by Stanislav Brabec
Modified: 2010-07-07 12:56 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stanislav Brabec 2009-11-19 17:53:25 UTC
Kernel has a sys_tz and FAT based file systems have a new mount option to control time zone of FAT file systems: tz=UTC.

The default for most FAT volumes is the local time (i. e. tz=UTC not used in mount options). In local time mode, kernel uses sys_tz kernel variable.

But sys_tz is not set, so all FAT based file systems are mounted with the time zone equal to UTC. It causes "several hours off" effect.

As far as I see, the only user space utility capable to set the sys_tz is the hwclock utility. But hwclock does not work as expected:

"hwclock --systz --utc" does nothing useful.

"hwclock --systz --localtime" sets sys_tz variable correctly but also reads hwclock and sets system clock, exactly as "hwclock --localtime --hctosys". It is not wanted in most cases.

Work-around:
hwclock --systz --localtime
hwclock --hctosys --utc
With exception of time race while called, it does what most people expect.

Correct fix:
It is mis-design of --systz. --systz either should not include --hctosys and set only sys_tz or --systz --utc should do something useful: set sys_tz to the correct time zone.

Note: other distributions probably have the same problem.
Comment 2 Petr Uzel 2010-07-07 12:56:13 UTC
This has been fixed upstream (and so the fix will be in 11.3).

[1] http://www.spinics.net/lists/util-linux-ng/msg02668.html