Windows "date modified" and daylight savings time

Thanks everyone, that was quite an educational thread.

Just curious, how do other operating systems (like Unix, Mac) handle
the file timestamp in regards to DST? Do they have the same problem,
or do they handle it better?

bucky3

On Tue, 3 Nov 2009 20:57:14 +0000 (UTC), Toxic <staring@my_hd.tv>
wrote:

>On Tue, 03 Nov 2009 13:56:43 +0000, David J Taylor wrote:
>
>> I keep my camera set to UTC rather than local time
>
>
>Good idea,
>and since I've got to go in and dither its clock one of these days,
>I think I'll do likewise.

My camera (Nikon D300) is set to synchronise time with my computer
every time I connect the two. The computer (Windows XP) shows local
time, including the adjustment for DST. It also is synchronised daily
with a time signal from somewhere (USN Hawaii?) All of this is very
convenient and much more meaningful than me having to maintain my
camera at UTC.



Eric Stevens

Eric Stevens

In article <2009110313342154666-savageduck1@REMOVESPAMmecom>,
Savageduck <savageduck1@{REMOVESPAM}me.com> wrote:

> > Just curious, how do other operating systems (like Unix, Mac) handle
> > the file timestamp in regards to DST? Do they have the same problem,
> > or do they handle it better?
>
> Apple provides an option for automatic date & time setting via one of 3
> online time servers; Apple Americas/U.S. (time.apple.com); Apple Asia
> (time.asia.apple.com); Apple Europe (time.euro.apple.com) this
> automatically handles all DST issues.

other time servers can be added and the time stamp is utc with a time
zone offset.

nospam

Savageduck <savageduck1@{REMOVESPAM}me.com> wrote:
>On 2009-11-03 13:25:30 -0800, bucky3 <> said:
>
>> Thanks everyone, that was quite an educational thread.
>>
>> Just curious, how do other operating systems (like Unix, Mac) handle
>> the file timestamp in regards to DST? Do they have the same problem,
>> or do they handle it better?
>
>Apple provides an option for automatic date & time setting via one of 3
>online time servers; Apple Americas/U.S. (time.apple.com); Apple Asia
>(time.asia.apple.com); Apple Europe (time.euro.apple.com) this
>automatically handles all DST issues.

So does Microsoft. And other organizations. But the time transmitted is
always UTC and any time zone settings are handled locally on your
computer according to your timezone settings. After all, how would the
server know if you are on the left side or right side of that time zone
border.

jue

Jürgen Exner

bucky3 wrote:
> Thanks everyone, that was quite an educational thread.
>
> Just curious, how do other operating systems (like Unix, Mac) handle
> the file timestamp in regards to DST? Do they have the same problem,
> or do they handle it better?

I believe the Unix-based systems (Linux, OSX, BSD) handle it correctly.


--
Bertrand

Ofnuts

Eric Stevens wrote:
> On Tue, 3 Nov 2009 20:57:14 +0000 (UTC), Toxic <staring@my_hd.tv>
> wrote:
>
>> On Tue, 03 Nov 2009 13:56:43 +0000, David J Taylor wrote:
>>
>>> I keep my camera set to UTC rather than local time
>>
>> Good idea,
>> and since I've got to go in and dither its clock one of these days,
>> I think I'll do likewise.
>
> My camera (Nikon D300) is set to synchronise time with my computer
> every time I connect the two. The computer (Windows XP) shows local
> time, including the adjustment for DST. It also is synchronised daily
> with a time signal from somewhere (USN Hawaii?) All of this is very
> convenient and much more meaningful than me having to maintain my
> camera at UTC.

It's also a lot easier if you geotag your photos using a GPS log file.

--
Bertrand

Ofnuts

bucky3 <> wrote:
>Just curious, how do other operating systems (like Unix, Mac) handle
>the file timestamp in regards to DST?

It's not an issue because all times/dates are stored in UTC (or actually
seconds since the epoch) and converted to local time for display
purposes only.

>Do they have the same problem,
>or do they handle it better?

Not sure how you define "problem" and "better". The exact time is
available, it is up to you as a user to decide how you want to display
it.

I think your problem is not a problem at all. Or maybe it's a problem
where there is no meaningful solution. Or maybe you didn't think it
through all the way. DST is only one very small factor in dealing with
local time.

Example: If photos have been taken in Sydney at lunch time and now you
are looking at those files back home in NewYork, what time stamp would
you expect: 13:00 (the local time at the place those files were created)
or 22:00 the previous day (the local time of when the files were created
at the place you are looking at the files now)?
Now imagine that you uploaded those files minutes after you took them to
your home server in NY, and another family member uploaded some other
photos locally in NY 2 hours later. What time sequence would you like to
see: your photos first or his photos first? Because by local time based
on where the photos were taken his would be first by 13 hours although
they were taken 2 hours after yours.

So no, there is no golden bullet and the only sensible option is indeed
using UTC and thus having an absolut target, that is not moving with
crossing each time zone boundary and not moving with every switch
between DST and non-DST, either.

jue

Jürgen Exner

"Eric Stevens" <> wrote in message
news:...
[]
> My camera (Nikon D300) is set to synchronise time with my computer
> every time I connect the two. The computer (Windows XP) shows local
> time, including the adjustment for DST. It also is synchronised daily
> with a time signal from somewhere (USN Hawaii?) All of this is very
> convenient and much more meaningful than me having to maintain my
> camera at UTC.
>
> Eric Stevens

If you want better than a daily sync, look at NTP:

http://www.meinberg.de/english/sw/ntp.htm

You can keep your PC within a fraction of a second using an Internet
connection.

Cheers,
David

David J Taylor

"Ofnuts" <> wrote in message
news:4af044f8$0$30818$...
> David J Taylor wrote:
>>
>> "Ofnuts" <> wrote in message
>> news:4af004ab$0$25364$...
>> []
>>> A timestamp is absolute. In computers it is stored as the number of
>>> seconds (or milliseconds, or nanoseconds) since a reference time
>>> (00:00 UTC on January 1st, 1970 for Unix and a lot of web-related
>>> things)(*).
>>
>> .. conveniently forgetting about things like leap seconds, perhaps?
>
> No, they are taken in account (assuming the display and parsing code are
> correct (mostly the display, since most serious computers
> self-synchronize via NTP).

Unix time ignores leap seconds, at least according to:

http://en.wikipedia.org/wiki/Unix_time

and that's my experience as well. The "number of seconds" does /not/
include the leap seconds. To test, try seeing whether the Unix time tor
the start of a day is exactly divisible by 86400 - e.g. 1257292800
(4-Nov-2009 at 00:00:00). If Unix time included the leap-second count,
the start of a day should be n * 86400 + 24. (IIRC).

[]
> Not even sure of the date part. If a file is stamped at 00:30 on June
> 21st, will Window show it later as stamped at 23:30 on June 21st or at
> 23:30 on June 20th?
>
> --
> Bertrand

An interesting point, although to some extent one I face all the time as,
for example, most of my "daytime" photographs taken in Australia cover
two UTC calendar days. As my camera and hence my EXIF information stays
on UTC, the photos have a continually increasing sequence number when
renamed, even over a winter/summer time change. My photos have a name -
typically:

2009-09-24-0826-57.jpg

Cheers,
David

David J Taylor

David J Taylor wrote:
> "Eric Stevens" <> wrote in message
> news:...
> []
>> My camera (Nikon D300) is set to synchronise time with my computer
>> every time I connect the two. The computer (Windows XP) shows local
>> time, including the adjustment for DST. It also is synchronised daily
>> with a time signal from somewhere (USN Hawaii?) All of this is very
>> convenient and much more meaningful than me having to maintain my
>> camera at UTC.
>>
>> Eric Stevens
>
> If you want better than a daily sync, look at NTP:
>
> http://www.meinberg.de/english/sw/ntp.htm
>
> You can keep your PC within a fraction of a second using an Internet
> connection.

You don't need "NTP for Windows" with Windows you know. The Windows Time
Service is quite capable of synchronizing to an NTP server, and in fact
Vista does that out of the box unless it's on a domain, in which case it
synchronizes to the domain controller.

On XP and earlier you have to do some digging to set it up, on Vista it's
set up right off the clock application in the system tray on the lower
right. For XP the procedure can be found at
http://support.microsoft.com/kb/314054#EXTERNAL. There's a link from there
to the procedure for Windows 2000.

J. Clarke