C++ CTime to .NET DateTime
-
I have an app that logs data and serialises a CTime to an archive ie
CTime time achive << timeI cannot for the life of me get .NET to read it from the file. I can get the same value from the file , its just that the code below produces a date somewhere in the 1600'sDateTime time=DataTime.FromBinary(theFileValue);I can load the value in a C++ MFC program and get the correct result HELP!!!! Thanks .Netter -
did you try to provide an IFormatProvider? This is an option which you can define how it's formatted.
its not the format , the date is totally incorrect, infact the date it reports is 12:01:53 AM on 1/1/0001. Ive tried all the .From options, none work.
-
its not the format , the date is totally incorrect, infact the date it reports is 12:01:53 AM on 1/1/0001. Ive tried all the .From options, none work.
-
in fact it just throws and invalid cast exception (as the documentation says)
-
in fact it just throws and invalid cast exception (as the documentation says)
Then i think you can use the same solution as i've just given down here:
string strDate = "20060502"; DateTime dtDate = DateTime.ParseExact( strDate, "yyyyMMdd", CultureInfo.InvariantCulture ); strDate = dtDate.ToString();Where y stands vor years M for months d for days h for hours m for minutes s for seconds Should this work?
-
Then i think you can use the same solution as i've just given down here:
string strDate = "20060502"; DateTime dtDate = DateTime.ParseExact( strDate, "yyyyMMdd", CultureInfo.InvariantCulture ); strDate = dtDate.ToString();Where y stands vor years M for months d for days h for hours m for minutes s for seconds Should this work?
The value is saved in the file as an int32, not a string, the problem is that the .net datetime doesnt interpret this value the same way MFC does with CTime.
-
The value is saved in the file as an int32, not a string, the problem is that the .net datetime doesnt interpret this value the same way MFC does with CTime.
You say the value is saved in the file as an int32. Is it the same as time_t (which is 32 bits)? If so, the C# DateTime is obtained as follows, where the variable "timet" contains your 32 bit time_t value: DateTime.FromFileTime(10000000 * (long)timet + 116444736000000000)
-
You say the value is saved in the file as an int32. Is it the same as time_t (which is 32 bits)? If so, the C# DateTime is obtained as follows, where the variable "timet" contains your 32 bit time_t value: DateTime.FromFileTime(10000000 * (long)timet + 116444736000000000)
i can't check it at the moment but that sounds about right. So thank you very much. Where did you fid that strange bit of information. Can't think I would have come up with that.
-
i can't check it at the moment but that sounds about right. So thank you very much. Where did you fid that strange bit of information. Can't think I would have come up with that.
>> Where did you find that strange bit of information It is not so strange if you analyze it. Those aren't "magical" numbers in that equation: DateTime.FromFileTime(10000000 * (long)timet + 116444736000000000) You can see from the method name that the quantity in parentheses is a FileTime. You already know that time_t is seconds since 1/1/1970. A FileTime is a long representing 100 nanosecond intervals since 1/1/1601. So all you need to do is multiply the time_t by 1e7 to get 100 nanosecond intervals, and then add the number of 100 nanosecond intervals between 1/1/1601 and 1/1/1970, which is easily calculated. Perfectly logical, no? Hahaha.
-
>> Where did you find that strange bit of information It is not so strange if you analyze it. Those aren't "magical" numbers in that equation: DateTime.FromFileTime(10000000 * (long)timet + 116444736000000000) You can see from the method name that the quantity in parentheses is a FileTime. You already know that time_t is seconds since 1/1/1970. A FileTime is a long representing 100 nanosecond intervals since 1/1/1601. So all you need to do is multiply the time_t by 1e7 to get 100 nanosecond intervals, and then add the number of 100 nanosecond intervals between 1/1/1601 and 1/1/1970, which is easily calculated. Perfectly logical, no? Hahaha.
Went to work , tested and thats it.Thank you