Re: UTC or localtime
On Wed, Jul 14, 2010 at 04:00:03PM +0000, T o n g wrote:
> On Tue, 13 Jul 2010 22:32:09 -0600, Dave Thayer wrote:
>
> >> The camera is the same. Something get changed on Debian side? How can I
> >> fix it? (photos are from mounted SD card via SD card reader).
> >
> > You could be getting bit by Bug #577597 - "system with UTC=yes in
> > /etc/default/rcS mounts FAT USB disk with wrong file time".
>[...\]
> Having UTC=yes in the /etc/default/rcS file means the Linux system is
> using UTC time? Then how about?
>
> $ date
> Wed Jul 14 11:49:39 EDT 2010
UTC=yes tells the system that the hardware clock is set in UTC, which
is a good idea on a linux-only system but can be a headache if you
dual-boot Windows. What is displayed when you use the date command
depends on how you answer the questions when you run tzselect. Under
the hood, the linux clock always works in UTC.
> > The bug
> > report contains the following work-around, as root run these commands:
> >
> > hwclock --systohc --utc
> > hwclock --hctosys --utc
>
> This fix change my BIOS CMOS clock using UTC, correct? Then when I boot
> into BIOS, will the time be correct localtime? How about when I boot into
> Windows, will it get confused?
>From reading the ubuntu bug linked to from Debian's bug #577597, what
appears to be happening is that an internal kernal flag which contains
timezone information is not getting properly set at startup. This
little routine must set the kernel flag.
> > My rockboxed ipod shows files with timestamps off by the time difference
> > between localtime and UTC, as if the tz=UTC option was selected in
> > mount, and when I apply the work-around in the bug report things are
> > straightened out.
>
> Wait a minute, from man page:
>
> The tz=UTC option "disables the conversion of timestamps between local
> time (as used by Windows on FAT) and UTC (which Linux uses internally).
> This is particuluarly useful when mounting devices (like digital cameras)
> that are set to UTC in order to avoid the pitfalls of local time."
I suspect that mount uses the kernel flag to obtain the timezone info
rather than the libc based information that the date and tzselect work
with. This makes sense since mount works at such a low level. If the
kernel timezone flag is not getting set then mount would be assuming
that you are in UTC, just as if the tz=UTC mount option had been used,
and incorrectly reports ctime and mtime.
Note that this is pure speculation on my part, perhaps there is a
lurking kernel hacker who can chime in and correct me.
dt
Reply to: