-
February 18th, 2004, 12:18 PM
#1
CTime question
I want to create a CTime object with this line of code:
CTime time(1970, 1, 1, 0, 0, 0).
In debug mode an assertion failure arises, even if in msdn it says the values used in constructor are in the valid ranges. Stepping into constructor I found that _mktime64() returns -1. Can somebody tell me what is going on???
-
February 18th, 2004, 12:26 PM
#2
Its working perfectly for me..
Can u post the entire code snippet please...
C++ is divine.
-
February 18th, 2004, 12:30 PM
#3
The problem with this date is that it is the equivalent of 0. For a lot of CTime functions, it is not considered a valid, even though it can be constructed that way.
The first really valid date would be:
CTime time(1970, 1, 1, 0, 0, 1);
I guess ...
Elrond
A chess genius is a human being who focuses vast, little-understood mental gifts and labors on an ultimately trivial human enterprise.
-- George Steiner
-
February 18th, 2004, 01:01 PM
#4
CTime question
Hi Kandukondein and Elrond. To let anybody know, the test was done on vc6 and .Net vc++ platforms. if i set greater values for hour, min or sec, the result is the same. if i set greater values for day, month or yesr, then it's ok. but i'm interested in that particular date 1st Jan 1970 0:0:0, and it still fails.
-
February 18th, 2004, 01:15 PM
#5
Here's the ctor for CTime
Code:
00025: CTime::CTime(int nYear, int nMonth, int nDay, int nHour, int nMin, int nSec,
00026: int nDST)
00027: {
00028: struct tm atm;
00029: atm.tm_sec = nSec;
00030: atm.tm_min = nMin;
00031: atm.tm_hour = nHour;
00032: ASSERT(nDay >= 1 && nDay <= 31);
00033: atm.tm_mday = nDay;
00034: ASSERT(nMonth >= 1 && nMonth <= 12);
00035: atm.tm_mon = nMonth - 1; // tm_mon is 0 based
00036: ASSERT(nYear >= 1900);
00037: atm.tm_year = nYear - 1900; // tm_year is 1900 based
00038: atm.tm_isdst = nDST;
00039: m_time = mktime(&atm);
00040: ASSERT(m_time != -1); // indicates an illegal input time
00041: }
Check out what happens with mktime()
-
February 18th, 2004, 01:25 PM
#6
Hi geo_m!
In what part of the world are you? If you construct your CTime like that some adjustments might be made for day light savings (DST) and for timezones. For example 1970 1 1 0 0 0 in London would be 1969 12 31 19 0 0 in New York if there's a 5 hour difference. This may be the source of problem.
-
February 19th, 2004, 04:35 AM
#7
geo_m is from Texas, so that could be a reason, though I think, except if you explicitely ask for it that CTime would use local time, ...
But may be you're right, though it seems geo_m has tried several values for the hour, but may be not high enough ...
Elrond
A chess genius is a human being who focuses vast, little-understood mental gifts and labors on an ultimately trivial human enterprise.
-- George Steiner
-
February 19th, 2004, 07:38 AM
#8
The date the you have supplied should work (and in fact it does for me and others) but it doesn't surprise me that a a limit value like this would faile on some computers.
If you are tracing into the CTime constructor why not just continue into _mktime() ? You will find that _make_time_t() is the function that does the error checking and returns -1. Unlike most Microsoft source code, it is reasonably well documented so you should be able do determine the precise reason for failure.
-
February 19th, 2004, 09:51 AM
#9
CTime question
Thank you all for your help, especially to Nelo. Starting with his sugestion, I tested again:
0. context: GMT +2:0
1. when using CTime( time_t time ) constructor, time MUST be considered in UTC coordinates.
2. when using CTime( int nYear, int nMonth, int nDay, int nHour, int nMin, int nSec, int nDST = -1 ) constructor, time values MUST be considered in time zone coordinates (takes into account data in timezone).
For instance:
1. CTime t(0)
is ok because 0 in UTC means 1st Jan 1970 0:0:0, and this data is first validated; after that is calculated time in time zone coordinates (in my case: UTC+2hours).
2. CTime t(1970, 1, 1, 0, 0, 0) is not ok because it assumes that this data is in time zone coordinates, so it will calculate the time in UTC by substracting 2 hours=> an invalid time (31 dec 1969 22:0:0), that's why an assertion fails.
Thank you all once again. For me, this subject is closed.
-
February 19th, 2004, 09:56 AM
#10
Thanks for the followup including a good description of what you found.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|