Datetimes on files from my phone are off by three hours

Duncan 1i5t5.duncan at
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 

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:
More info:

More information about the kde mailing list