«

I have some old data files with old timestamps, where
timestmap=time(NULL), some of them date back to the
year 1999.

I want to my code to print the timestamps and each one to
include hour:minute:second as of the corresponding old day.
The only routine for this job seems to be
localtime(timestmap) - this is Windows Vista,
Visual Studio 2005 C++.


localtime() seems to consider the presence of Daylight Saving
Time for the current day when it is actually called, but it does
not seem to consider the presence of Daylight Saving Time
for the old day.


For example, I run localtime on a timestamp from 3-22-1999
(Daylight Saving Time was not effective yet) today when Daylight
Saving Time is effective and localtime() returns hour:minute:second
one hour later as it should.


Does it mean that the only way around it is to keep transition
dates for Daylight Saving Time for all years and have my code
make the adjustments depending on the old day and the current
day? Is there any utility to do that or any better way?

"" <> writes:
> I have some old data files with old timestamps, where
> timestmap=time(NULL), some of them date back to the
> year 1999.
>
> I want to my code to print the timestamps and each one to
> include hour:minute:second as of the corresponding old day.
> The only routine for this job seems to be
> localtime(timestmap) - this is Windows Vista,
> Visual Studio 2005 C++.
>
> localtime() seems to consider the presence of Daylight Saving
> Time for the current day when it is actually called, but it does
> not seem to consider the presence of Daylight Saving Time
> for the old day.
[...]

It sounds like your system's implementation of localtime() is buggy.
There may not be much you can do to correct it, but workarounds are
possible.

> For example, I run localtime on a timestamp from 3-22-1999
> (Daylight Saving Time was not effective yet) today when Daylight
> Saving Time is effective and localtime() returns hour:minute:second
> one hour later as it should.
>
> Does it mean that the only way around it is to keep transition
> dates for Daylight Saving Time for all years and have my code
> make the adjustments depending on the old day and the current
> day? Is there any utility to do that or any better way?

That would be one solution, but it could break if a future version of
your implementation corrects the bug in localtime().

An alternative might be to use gmtime() and do the conversion to local
time yourself. But that requires knowing about the time zone, which
varies from place to place, within a year (as DST comes and goes), and
over history (as DST rules change, either nationally or locally).

I think there are time zone libraries that already include much of
this information (<OT>Googling "tzdata" may be helpful</OT>).

It's also likely that there's a system-specific solution. Try a
newsgroup that deals with Windows and/or with Visual Studio 2005 C++.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

wrote:
> I have some old data files with old timestamps, where
> timestmap=time(NULL), some of them date back to the
> year 1999.
>
> localtime() seems to consider the presence of Daylight Saving
> Time for the current day when it is actually called, but it does
> not seem to consider the presence of Daylight Saving Time
> for the old day.
>
>
> For example, I run localtime on a timestamp from 3-22-1999
> (Daylight Saving Time was not effective yet) today when Daylight
> Saving Time is effective and localtime() returns hour:minute:second
> one hour later as it should.
>
>
> Does it mean that the only way around it is to keep transition
> dates for Daylight Saving Time for all years and have my code
> make the adjustments depending on the old day and the current
> day? Is there any utility to do that or any better way?
>

Check the value of tm_isdst. If the value is positive then DST is
in effect, if it's zero then DST is not in effect. If that value
is negative then that information is not available. Unless you
get a negative value you should have correct DST information
provided that your system has up to date time zone information.
It may not be your case but time_t range and precision are
implementation defined and they can actually be different between
different versions of the same compiler.

Can you give me some timestamps, the tm values you get and the tm
values you expect?

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

In article < .com>,
<> wrote:
>I want to my code to print the timestamps and each one to
>include hour:minute:second as of the corresponding old day.
>The only routine for this job seems to be
>localtime(timestmap) - this is Windows Vista,
>Visual Studio 2005 C++.

>localtime() seems to consider the presence of Daylight Saving
>Time for the current day when it is actually called, but it does
>not seem to consider the presence of Daylight Saving Time
>for the old day.

I've recently read (in comp.risks I think it was) that this
is a long-standing Windows issue that Microsoft has refused to change.

However, as this is a system-specific behaviour and I could
easily be wrong (or have misinterpreted), you will need to
check in a Windows programming newgroup.
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell

On May 11, 4:23 pm, Keith Thompson <k...@mib.org> wrote:
> "mar...@hotmail.com" <mar...@hotmail.com> writes:
> > I have some old data files with old timestamps, where
> > timestmap=time(NULL), some of them date back to the
> > year 1999.
>
> > I want to my code to print the timestamps and each one to
> > include hour:minute:second as of the corresponding old day.
> > The only routine for this job seems to be
> > localtime(timestmap) - this is Windows Vista,
> > Visual Studio 2005 C++.
>
> > localtime() seems to consider the presence of Daylight Saving
> > Time for the current day when it is actually called, but it does
> > not seem to consider the presence of Daylight Saving Time
> > for the old day.
>
> [...]
>
> It sounds like your system's implementation of localtime() is buggy.
> There may not be much you can do to correct it, but workarounds are
> possible.
>


So what the non-buggy systems do? They actually save the DST
transition
dates for all past years. I do not think the dates are fixed and may
change
from year to year.

On May 11, 4:24 pm, Nelu <spamah...@gmail.com> wrote:
> mar...@hotmail.com wrote:
> > I have some old data files with old timestamps, where
> > timestmap=time(NULL), some of them date back to the
> > year 1999.
>
> > localtime() seems to consider the presence of Daylight Saving
> > Time for the current day when it is actually called, but it does
> > not seem to consider the presence of Daylight Saving Time
> > for the old day.
>
> > For example, I run localtime on a timestamp from 3-22-1999
> > (Daylight Saving Time was not effective yet) today when Daylight
> > Saving Time is effective and localtime() returns hour:minute:second
> > one hour later as it should.
>
> > Does it mean that the only way around it is to keep transition
> > dates for Daylight Saving Time for all years and have my code
> > make the adjustments depending on the old day and the current
> > day? Is there any utility to do that or any better way?
>
> Check the value of tm_isdst. If the value is positive then DST is
> in effect, if it's zero then DST is not in effect. If that value
> is negative then that information is not available. Unless you
> get a negative value you should have correct DST information
> provided that your system has up to date time zone information.
> It may not be your case but time_t range and precision are
> implementation defined and they can actually be different between
> different versions of the same compiler.
>
> Can you give me some timestamps, the tm values you get and the tm
> values you expect?
>

isdst field is set to 1, apparently on the basis of *current" DST,
the old timestamp is not supposed to have DST.

localtime() should ignore the current DST, obviously it should
assume some timezone and the current timezone is fine.

wrote:
> On May 11, 4:24 pm, Nelu <spamah...@gmail.com> wrote:
>> mar...@hotmail.com wrote:
>>> I have some old data files with old timestamps, where
>>> timestmap=time(NULL), some of them date back to the
>>> year 1999.
>>> localtime() seems to consider the presence of Daylight Saving
>>> Time for the current day when it is actually called, but it does
>>> not seem to consider the presence of Daylight Saving Time
>>> for the old day.
>>> For example, I run localtime on a timestamp from 3-22-1999
>>> (Daylight Saving Time was not effective yet) today when Daylight
>>> Saving Time is effective and localtime() returns hour:minute:second
>>> one hour later as it should.
>>> Does it mean that the only way around it is to keep transition
>>> dates for Daylight Saving Time for all years and have my code
>>> make the adjustments depending on the old day and the current
>>> day? Is there any utility to do that or any better way?
>> Check the value of tm_isdst. If the value is positive then DST is
>> in effect, if it's zero then DST is not in effect. If that value
>> is negative then that information is not available. Unless you
>> get a negative value you should have correct DST information
>> provided that your system has up to date time zone information.
>> It may not be your case but time_t range and precision are
>> implementation defined and they can actually be different between
>> different versions of the same compiler.
>>
>> Can you give me some timestamps, the tm values you get and the tm
>> values you expect?
>>
>
> isdst field is set to 1, apparently on the basis of *current" DST,
> the old timestamp is not supposed to have DST.

Then this may be a bug. The broken down time that localtime
returns should have all the fields reflecting the characteristics
of the calendar time (time_t).

> localtime() should ignore the current DST, obviously it should
> assume some timezone and the current timezone is fine.

Take a look at this, maybe it applies to your problem, as well:
http://support.microsoft.com/kb/129574


--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

On May 11, 3:25 pm, "mar...@hotmail.com" <mar...@hotmail.com> wrote:
> On May 11, 4:23 pm, Keith Thompson <k...@mib.org> wrote:
> > "mar...@hotmail.com" <mar...@hotmail.com> writes:
> > > I have some old data files with old timestamps, where
> > > timestmap=time(NULL), some of them date back to the
> > > year 1999.
>
> > > I want to my code to print the timestamps and each one to
> > > include hour:minute:second as of the corresponding old day.
> > > The only routine for this job seems to be
> > > localtime(timestmap) - this is Windows Vista,
> > > Visual Studio 2005 C++.
>
> > > localtime() seems to consider the presence of Daylight Saving
> > > Time for the current day when it is actually called, but it does
> > > not seem to consider the presence of Daylight Saving Time
> > > for the old day.
>
> > [...]
>
> > It sounds like your system's implementation of localtime() is buggy.
> > There may not be much you can do to correct it, but workarounds are
> > possible.
>
> So what the non-buggy systems do? They actually save the DST
> transition dates for all past years. I do not think the dates are
> fixed and may change from year to year.

<OT>Yes; as keith said (but you cut) 'Googling "tzdata" may be
helpful'</OT>.

> > isdst field is set to 1, apparently on the basis of *current" DST,
> > the old timestamp is not supposed to have DST.
>
> Then this may be a bug. The broken down time that localtime
> returns should have all the fields reflecting the characteristics
> of the calendar time (time_t).
>

Why a bug? This could be just an easy way out. This is not
documented one way or another.

> > localtime() should ignore the current DST, obviously it should
> > assume some timezone and the current timezone is fine.
>
> Take a look at this, maybe it applies to your problem, as well:http://support.microsoft.com/kb/129574
>

This link is just a basic explanation of DST impact on the *current*
time.
The issue here is whether Windows is able to find out DST of an *OLD*
time.

wrote:
>>> isdst field is set to 1, apparently on the basis of *current" DST,
>>> the old timestamp is not supposed to have DST.
>> Then this may be a bug. The broken down time that localtime
>> returns should have all the fields reflecting the characteristics
>> of the calendar time (time_t).
>>
>
> Why a bug? This could be just an easy way out. This is not
> documented one way or another.

The things about tm_isdst were taken from the C standard (n1124
draft). If they can't figure out the DST they must return -1 and
this would be the easy way out. They can't return 0 or 1 if they
don't know the DST.

>
>>> localtime() should ignore the current DST, obviously it should
>>> assume some timezone and the current timezone is fine.
>> Take a look at this, maybe it applies to your problem, as well:http://support.microsoft.com/kb/129574
>>
>
> This link is just a basic explanation of DST impact on the *current*
> time.
> The issue here is whether Windows is able to find out DST of an *OLD*
> time.
>
>

"SUMMARY
When Windows NT automatically adjusts for daylight saving time,
the times on files on Windows NT file system (NTFS) partitions
and the events in the event logs are retroactively shifted by one
hour, even though the files and event records were created before
the daylight saving time change. "

They will most likely not take each file in turn and shift the
time, they will change the meaning of the timestamp, which is
what your problem is and, as I was quoting earlier from the
standard, they are allowed to do this, however, they are not
allowed to lie. This is also the reason why you should never use
the value of time_t returned by the time family of functions to
store dates for long term.


--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)