Problem about time_t, localtime in Vc2005, possible bug ?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi There,

I just found that there is a problem in vc2005 regarding to time_t and
localtime. See code snippets belows. Using this code segment, I found that
when ut is 86200, the corresponding output is 1970.1.1 7:56:40, when ut is 0,
the output is 1970.1.1 8:00:00, when ut is 86400, the output is 1970.1.2
8:00:00. While output will be 1970 1.2 7:56:40 in VC8. Please note that I
am aware that time_t is 64bit in VC2005 and using _USE_32BIT_TIME_T can force
time_t behave like 32bit, but don't plan to use this workaround.

time_t ut;
ut = (time_t) 86200;
struct tm tm = *localtime(&ut);
cout << tm.tm_year << endl;
cout << tm.tm_mon << endl;
cout << tm.tm_mday << endl;
cout << tm.tm_hour << endl;
cout << tm.tm_min << endl;
cout << tm.tm_sec << endl;

Any comments/thoughts/suggestions is highly appreciated.

Thanks,
-Yuanfei
 
Hi There,

I just found that there is a problem in vc2005 regarding to time_t and
localtime. See code snippets belows. Using this code segment, I found that
when ut is 86200, the corresponding output is 1970.1.1 7:56:40, when ut is 0,
the output is 1970.1.1 8:00:00, when ut is 86400, the output is 1970.1.2
8:00:00. While output will be 1970 1.2 7:56:40 in VC8. Please note that I
am aware that time_t is 64bit in VC2005 and using _USE_32BIT_TIME_T can force
time_t behave like 32bit, but don't plan to use this workaround.

time_t ut;
ut = (time_t) 86200;
struct tm tm = *localtime(&ut);
cout << tm.tm_year << endl;
cout << tm.tm_mon << endl;
cout << tm.tm_mday << endl;
cout << tm.tm_hour << endl;
cout << tm.tm_min << endl;
cout << tm.tm_sec << endl;

Any comments/thoughts/suggestions is highly appreciated.
Click to expand...

What time zone are you in? Also, go ahead and finish writing this up as a
console program to make it easier for others to try, and talk about its
actual output. Finally, it's not clear what the problem is; you didn't say
which compiler gave you the good(?) results, and it's not clear what input
applies to the sentence fragment "While output will be 1970 1.2 7:56:40 in
VC8".
 
Thanks Doug for reminding me.

1) My time zone is GMT+8:00

2) The OS of my bos is XP Professional, SP2

3) The repro code is belows:
#include <iostream>
#include <time.h>
void main()
{
using namespace std;
time_t ut;
ut = 86200;
struct tm tm = *localtime(&ut);
cout << "The time is" << tm.tm_year+1900 <<" " << tm.tm_mon+1 <<" " <<
tm.tm_mday << " ";
cout << tm.tm_hour << ":" << tm.tm_min << ":" << tm.tm_sec << endl;

ut = 86400;
tm = *localtime(&ut);
cout << "The time is" << tm.tm_year+1900 <<" " << tm.tm_mon+1 <<" " <<
tm.tm_mday << " ";
cout << tm.tm_hour << ":" << tm.tm_min << ":" << tm.tm_sec << endl;
}


4) And the result of the program above is:
On VC8:
The time is: 1970 1 1 7:56:40
The time is: 1970 1 2 8:0:0

On VC6:
The time is: 1970 1 2 7:56:40
The time is: 1970 1 2 8:0:0

5) Of course, adding _USE_32BIT_TIME_T to VC8 project will make the result
of the program in VC8 being same as that in VC6.

6) Note that when ut is 86200, the value of tm.tm_mday should be 2 instead
of 1. Because 86400 's corresponding tm.tm_mday's value is 1.

7) My question is:

* If the behavior of the code above in VC8 is expected and corrected ?
* If yes, I wonder if there are any patch availalbe for this issue ?
* If it's not bug, how can I change my code to get the expected value "The
time is: 1970 1 2 7:56:40" when ut is 86200 ?


Thanks,
-Yuanfei
 
Thanks Doug for reminding me.

1) My time zone is GMT+8:00

2) The OS of my bos is XP Professional, SP2

3) The repro code is belows:
#include <iostream>
#include <time.h>
void main()
{
using namespace std;
time_t ut;
ut = 86200;
struct tm tm = *localtime(&ut);
cout << "The time is" << tm.tm_year+1900 <<" " << tm.tm_mon+1 <<" " <<
tm.tm_mday << " ";
cout << tm.tm_hour << ":" << tm.tm_min << ":" << tm.tm_sec << endl;

ut = 86400;
tm = *localtime(&ut);
cout << "The time is" << tm.tm_year+1900 <<" " << tm.tm_mon+1 <<" " <<
tm.tm_mday << " ";
cout << tm.tm_hour << ":" << tm.tm_min << ":" << tm.tm_sec << endl;
}


4) And the result of the program above is:
On VC8:
The time is: 1970 1 1 7:56:40
The time is: 1970 1 2 8:0:0

On VC6:
The time is: 1970 1 2 7:56:40
The time is: 1970 1 2 8:0:0

5) Of course, adding _USE_32BIT_TIME_T to VC8 project will make the result
of the program in VC8 being same as that in VC6.

6) Note that when ut is 86200, the value of tm.tm_mday should be 2 instead
of 1. Because 86400 's corresponding tm.tm_mday's value is 1.
Click to expand...

You mean 2, right?
7) My question is:

* If the behavior of the code above in VC8 is expected and corrected ?
* If yes, I wonder if there are any patch availalbe for this issue ?
* If it's not bug, how can I change my code to get the expected value "The
time is: 1970 1 2 7:56:40" when ut is 86200 ?
Click to expand...

Yeah, I'd expect the day of the month to change if the times were 23:56:40
and 0:00:00. I can repro this by adding the following to your code:

_putenv("TZ=XXX-8");
_tzset();

MS now has an excellent bug reporting facility:

http://lab.msdn.microsoft.com/productfeedback/Default.aspx

I suggest you enter a bug report there and post the link you receive so
others can follow it.
 
Yuanfei said:
Hi Doug,

Thanks for your suggestion.

I have filed a bug, and its link is
http://lab.msdn.microsoft.com/Produ...edbackid=9dd0b68b-4c04-4c6a-8ece-f0e798a99f5a.

Cheers,
-Yuanfei
Click to expand...

I too have reproduced this problem. It seems to occur when the local
time is within the local to GMT time difference, but only for the
64-bit localtime() function, and only for the first 4 days of 1970. I
wrote a quick program to check 60-second intervals thereafter with no
problems found (unless at some point the 32 and 64 bit localtimes()s
have the same bug!)

Chris
 
I too have reproduced this problem. It seems to occur when the local
time is within the local to GMT time difference, but only for the
64-bit localtime() function, and only for the first 4 days of 1970. I
wrote a quick program to check 60-second intervals thereafter with no
problems found (unless at some point the 32 and 64 bit localtimes()s
have the same bug!)
Click to expand...

Apparently this bug was reported before and has since been fixed, but there
is no further info given:

http://lab.msdn.microsoft.com/produ...edbackid=9dd0b68b-4c04-4c6a-8ece-f0e798a99f5a
 
I called M$ at a number provided by online agent, and get the final answer
that we are on our own on this bug, all the thing I can do on this is to wait
and search internet to see if there is new hotfix or patch. Sigh...

-Yuanfei
 
Back
Top