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???
Its working perfectly for me..
Can u post the entire code snippet please...
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 ...
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.
Here's the ctor for CTime
Check out what happens with mktime()
00025: CTime::CTime(int nYear, int nMonth, int nDay, int nHour, int nMin, int nSec,
00026: int nDST)
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
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.
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 ...
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.
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).
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.
Thanks for the followup including a good description of what you found.