Windows "date modified" and daylight savings time

I just realized that now all my files' "Date Modified" are 1 hr off
after daylight savings time. This is obvious when you compare the Date
Modified vs EXIF date picture taken.

After some research, I learned that the Date Modified timestamp is
recorded in UTC. Then it is displayed with the current timezone
adjustment. So before DST, if I had a file modified at 14:00 UTC, and
my timezone was PDT(-7), then Windows file explorer would display the
time stamp as 7:00, which was correct. But now that it is DST, which
is PST(-, Windows is displaying the time stamp as 6:00, which is
incorrect.

Is there a way to have Windows XP display the correct time stamp? I
think it should take into account the date of the timestamp and figure
out whether it was during DST or not. So a timestamp of 6/1/2009 14:00
would be adjusted -7:00 to 7:00 (since 6/1/2009 was during DST).
Whereas a timestamp of 1/1/2009 14:00 would be adjusted -8:00 to 6:00
(since 1/1/2009 was not DST).

bucky3

On Nov 2, 9:21 am, bucky3 <buc...@mail.com> wrote:
> So before DST, if I had a file modified at 14:00 UTC, and
> my timezone was PDT(-7), then Windows file explorer would display the
> time stamp as 7:00, which was correct. But now that it is DST, which
> is PST(-, Windows is displaying the time stamp as 6:00, which is
> incorrect.

Correction:

So *DURING* DST, if I had a file modified at 14:00 UTC, and
my timezone was PDT(-7), then Windows file explorer would display the
time stamp as 7:00, which was correct. But now that it is *NO LONGER*
DST, which
is PST(-, Windows is displaying the time stamp as 6:00, which is
incorrect.

bucky3

"bucky3" <> wrote in message
news:5072e4d8-79c4-4ffd-82a7-...
> On Nov 2, 9:21 am, bucky3 <buc...@mail.com> wrote:
>> So before DST, if I had a file modified at 14:00 UTC, and
>> my timezone was PDT(-7), then Windows file explorer would display the
>> time stamp as 7:00, which was correct. But now that it is DST, which
>> is PST(-, Windows is displaying the time stamp as 6:00, which is
>> incorrect.
>
> Correction:
>
> So *DURING* DST, if I had a file modified at 14:00 UTC, and
> my timezone was PDT(-7), then Windows file explorer would display the
> time stamp as 7:00, which was correct. But now that it is *NO LONGER*
> DST, which
> is PST(-, Windows is displaying the time stamp as 6:00, which is
> incorrect.

Why is it incorrect? The file was modified at a fixed time, to which is
either added or not an hour. 06:00 normal time => 07:00 summer time.
14:00 - 8 hours => 06:00.

If you always want "wall-clock" time displayed for files, store then on a
FAT-16 file system. Possibly even a FAT-32 volume, but I haven't checked
that.

Cheers,
David

David J Taylor

David J Taylor wrote:
>
> "bucky3" <> wrote in message
> news:5072e4d8-79c4-4ffd-82a7-...
>> On Nov 2, 9:21 am, bucky3 <buc...@mail.com> wrote:
>>> So before DST, if I had a file modified at 14:00 UTC, and
>>> my timezone was PDT(-7), then Windows file explorer would display the
>>> time stamp as 7:00, which was correct. But now that it is DST, which
>>> is PST(-, Windows is displaying the time stamp as 6:00, which is
>>> incorrect.
>>
>> Correction:
>>
>> So *DURING* DST, if I had a file modified at 14:00 UTC, and
>> my timezone was PDT(-7), then Windows file explorer would display the
>> time stamp as 7:00, which was correct. But now that it is *NO LONGER*
>> DST, which
>> is PST(-, Windows is displaying the time stamp as 6:00, which is
>> incorrect.
>
> Why is it incorrect? The file was modified at a fixed time, to which is
> either added or not an hour. 06:00 normal time => 07:00 summer time.
> 14:00 - 8 hours => 06:00.

You're both wrong When going DST, you don't change timezones. You
stay in the same timezone, but apply DST.

In this time zone, June 21st, 12:00 is the way to denote a specific
moment in time(*), and there is only one way to denote a specific moment
in that time zone. If you went to lunch at 12:00 on that day, you aren't
going to tell you went to lunch at 11:00 if you tell a story about it
later in winter (unless it's used as an alibi and you are trying to fool
a detective).

So if a file has a June 21st 12:00 timestamp, the computer should always
display it as June 21st 12:00 as long as it is set up in that time zone,
whether DST applies or not. Of course, if the computer is configured in
the next timezone, then the same timestamp can be displayed as June
21st, 11:00, and this will be the correct display in summer and winter
in that time zone.

So yes, Windows is broken
(<http://www.peterdonis.net/computers/computersarticle3.html>), but
what's new?

(*) except for the "duplicate hour" that happens during the fallback night,

--
Bertrand

Ofnuts

"Ofnuts" <> wrote in message
news:4aef509d$0$12528$...
[]
> So if a file has a June 21st 12:00 timestamp, the computer should always
> display it as June 21st 12:00 as long as it is set up in that time zone,
> whether DST applies or not. Of course, if the computer is configured in
> the next timezone, then the same timestamp can be displayed as June
> 21st, 11:00, and this will be the correct display in summer and winter
> in that time zone.
[]
> Bertrand

Yes, I can see your argument, but if you take it to its logical
conclusion, wouldn't you need to include the different time zone of the
taking device in your calculation of displayed date as well as the time
zone of the display device, so pictures taken at the same instant would
show a different timestamp if they were taken in New York, London or
Paris?

Cheers,
David

David J Taylor

David J Taylor wrote:
> "Ofnuts" <> wrote in message news:4aef509d$0$12528$...
> []
>> So if a file has a June 21st 12:00 timestamp, the computer should
>> always display it as June 21st 12:00 as long as it is set up in that
>> time zone, whether DST applies or not. Of course, if the computer is
>> configured in the next timezone, then the same timestamp can be
>> displayed as June 21st, 11:00, and this will be the correct display in
>> summer and winter in that time zone.
> []
>> Bertrand
>
> Yes, I can see your argument, but if you take it to its logical
> conclusion, wouldn't you need to include the different time zone of the
> taking device in your calculation of displayed date as well as the time
> zone of the display device, so pictures taken at the same instant would
> show a different timestamp if they were taken in New York, London or Paris?

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)(*).
Whether it is later displayed as June 21st, 12:00 or June 21st, 09:00
depends only on the "reader". In other words the timezone is nothing
more than a parameter when displaying or parsing date representations,
and unless it is implicit (but with computers, "implicit" is seldom a
good idea) it should be part of the display or input string. Giving a
time as "2009/11/03 12:00" without a time zone is a bit like giving an
appointment at 12:00 but not telling which day. So, ideally, your three
cameras would attach the very same time stamp to the three photos.

However, the people who did the Exif standard overlooked the
timezone/DST problem. The timestamp is stored as a "YYYY:MMD HH:MM:SS"
character string, and doesn't include a time zone. So this information
is lost and if the three cameras above are on local time, they will
store a different timestamp string. If the standard had provided for a
time zone, they would have stored something like "2009/11/03 12:00
UTC+0" in London, "2009/11/03 13:00 UTC+1" in Paris, and "2009/11/03
07:00 UTC-5" in NY which are three different representations of the very
same timestamp.

And the cherry on the cake is that the FAT/FAT32 file system used in
memory cards uses local time, and files are often transferred between
camera and computer using a card reader, so unless the camera is
carefully kept on local time things can get quite fun later, for
instance when geotagging the pictures.


(*) see "epoch" on Wikipedia
--
Bertrand

Ofnuts

"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?

> Whether it is later displayed as June 21st, 12:00 or June 21st, 09:00
> depends only on the "reader". In other words the timezone is nothing
> more than a parameter when displaying or parsing date representations,
> and unless it is implicit (but with computers, "implicit" is seldom a
> good idea) it should be part of the display or input string.

Agreed.

> Giving a time as "2009/11/03 12:00" without a time zone is a bit like
> giving an appointment at 12:00 but not telling which day. So, ideally,
> your three cameras would attach the very same time stamp to the three
> photos.

That would depend how the users have the cameras set, of course.

> However, the people who did the Exif standard overlooked the
> timezone/DST problem. The timestamp is stored as a "YYYY:MMD HH:MM:SS"
> character string, and doesn't include a time zone. So this information
> is lost and if the three cameras above are on local time, they will
> store a different timestamp string. If the standard had provided for a
> time zone, they would have stored something like "2009/11/03 12:00
> UTC+0" in London, "2009/11/03 13:00 UTC+1" in Paris, and "2009/11/03
> 07:00 UTC-5" in NY which are three different representations of the very
> same timestamp.

... and once lost, it's gone forever.

> And the cherry on the cake is that the FAT/FAT32 file system used in
> memory cards uses local time, and files are often transferred between
> camera and computer using a card reader, so unless the camera is
> carefully kept on local time things can get quite fun later, for
> instance when geotagging the pictures.
>
>
> (*) see "epoch" on Wikipedia
> --
> Bertrand

It can also be fun if:

- you take pictures before the time-change, and upload them to your
computer afterwards.

- you take pictures in one time-zone and upload them in another

and I'm sure you can think of even more circumstances. For those reasons,
I keep my camera set to UTC rather than local time, and I don't change it
between summer and winter. I don't bother about leap seconds on the
camera, as its clock isn't accurate enough to warrant it.

It is an important point to know that Windows displays the time with the
actual date, and the current offset time, rather than the time offset for
the taking date.

Cheers,
David

David J Taylor

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).

>> Whether it is later displayed as June 21st, 12:00 or June 21st, 09:00
>> depends only on the "reader". In other words the timezone is nothing
>> more than a parameter when displaying or parsing date representations,
>> and unless it is implicit (but with computers, "implicit" is seldom a
>> good idea) it should be part of the display or input string.
>
> Agreed.
>
>> Giving a time as "2009/11/03 12:00" without a time zone is a bit like
>> giving an appointment at 12:00 but not telling which day. So, ideally,
>> your three cameras would attach the very same time stamp to the three
>> photos.
>
> That would depend how the users have the cameras set, of course.

This assumes that the cameras would have a way to know the "absolute"
time (ie, set to UTC, or given a timezone).

> It is an important point to know that Windows displays the time with the
> actual date, and the current offset time, rather than the time offset
> for the taking date.
>

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

Ofnuts

Ofnuts wrote:
> 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).
>
>>> Whether it is later displayed as June 21st, 12:00 or June 21st, 09:00
>>> depends only on the "reader". In other words the timezone is nothing
>>> more than a parameter when displaying or parsing date
>>> representations, and unless it is implicit (but with computers,
>>> "implicit" is seldom a good idea) it should be part of the display or
>>> input string.
>>
>> Agreed.
>>
>>> Giving a time as "2009/11/03 12:00" without a time zone is a bit like
>>> giving an appointment at 12:00 but not telling which day. So,
>>> ideally, your three cameras would attach the very same time stamp to
>>> the three photos.
>>
>> That would depend how the users have the cameras set, of course.
>
> This assumes that the cameras would have a way to know the "absolute"
> time (ie, set to UTC, or given a timezone).
>
>> It is an important point to know that Windows displays the time with
>> the actual date, and the current offset time, rather than the time
>> offset for the taking date.
>>
>
> 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?
>

There is no easy universal way around these problems. Fortunately in the
grand scheme of things it's not a big deal as long as you are aware of
what's happening. If one is that picky, set the camera to UTC, keep it
that way and just do a mental adjustment as needed.

Dave Cohen

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.

Toxic