Datetimes on files from my phone are off by three hours
Duncan
1i5t5.duncan at cox.net
Mon Feb 7 23:58:06 GMT 2011
Dotan Cohen posted on Mon, 07 Feb 2011 11:37:04 +0200 as excerpted:
> When I transfer files from my phone (Nokia N86) to my Kubuntu system
> (KDE 4.6) I see that the datetimes are off by 3 hours. Therefore, it is
> probably a time zone issue. The phone is correctly configured for my
> timezone, as is the computer. What must I do to get the correct time in
> files transfered from the phone?
You are I believe correct, it's a time-zone issue, but I'm not sure it's a
bug, as one way or the other, it (see below) would be wrong for some
people, and I don't believe there's a way to auto-detect/auto-correct the
problem, tho it should be possible to correct it on your system... but
with other possible side effects that you might not like.
Linux (and I believe POSIX systems in general) have two ways to match
timezone time. POSIX standard says set the hardware clock to UTC, which
is what the system/software clock is supposed to use as well, then
configure your system to display local time (doing its conversion
internally) if desired.
One reason for this is that UTC doesn't have the ambiguity of "summer" aka
"daylight savings" time, which results in skipping an hour in the spring,
when clocks move ahead, and repeating an hour in the fall, when clocks
move back. The skipping isn't so bad as at least there's no ambiguity
there, but repeating... if the file was created in the repeated time,
should the system treat it as the first or the second repeat of that
time? Thus the POSIX standard specifies a system clock of UTC, avoiding
both that problem and the problem of dates/times for switching varying by
jurisdiction otherwise making "absolute" times for files even harder to
track. (FWIW, this spring-forward/fall-back nonsense is one reason I'm
glad I'm living somewhere that doesn't do it. I could fill an entire post
with discussion thereof, but I won't.)
The other option is to set the hardware clock to local time, but as I
understand it, the system still uses UTC internally, unless you
effectively tell it that it's UTC (set that as the timezone) but set it to
local time instead, and manage any changes manually.
Meanwhile, AFAIK, most phones are "phone-system time-synced", so that side
may well be out of your control entirely, meaning your only choice is to
adjust the computer side (unless by chance there's a config option for it
in your syncing tools, would make sense to me, to deal with exactly this
sort of issue...).
The problem with filetimes on files transferred from your phone,
therefore, is most likely due to one of two issues. Either they come with
timestamps but no zone info so the computer has to arbitrarily decide
whether they're UTC or local timezone, and is making the wrong choice (the
perfect case for having a configure option in the syncing tools to cover
the problem), or, perhaps, your computer is in the latter category above,
set to use UTC but you're manually managing its time and have set it for
local time instead of properly setting the timezone, thus resulting in the
computer screwing things up when it automatically adjusts the time for the
sync, because it's acting on the incorrect assumption that it's operating
on UTC, when it's not.
In the latter case, the fix is obvious. Correct the computer's
assumptions about its timezone and set both the time and the timezone
properly, so it can do the sync conversion using correct assumptions.
One caveat here: While POSIX specifies UTC as the internal system time
(thus avoiding time consistency issues as mentioned above), MS, at least
older MS (I've not run their servantware in nearing a decade, now, and
haven't kept up, but AFAIK this applied thru eXPrivacy at least), expects
the hardware clock to be local time, so if you dual-boot, you might need
to set the hardware clock to local, then tell Linux to make the conversion
as it boots. (I can describe my settings on Gentoo, if that'd help, as
hardware is set local not due to servantware I won't run but because I
like it that way, here, tho I don't have to deal with the spring-forward/
fall-back issues due to jurisdiction, so it's certainly possible, but
Gentoo specifics probably won't help you...)
Otherwise... see if there's an option for that in the syncing tools you
use, or try toggling the hardware clock to the other time, UTC or local,
and changing the appropriate Linux timezone settings, and see if that
helps.
Or devise a workaround. Here, I might just setup a script, preferrably
hooked into the sync itself if possible, or called manually before/after
if not, that takes a list of files and adjusts the times as appropriate...
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
More information about the kde
mailing list