COleDateTime
-
I have an application in which time values are transferred byte-by-byte to an Arduino via USB/COM. I have now realised that using CTime objects will suffer from the 19 January 2038 problem where, after this date, GetTime() will return negative values due to the return value being signed. It appears that use of COleDateTime with CTimeSpan ::GetTotalSeconds will avoid this as the return value is an unsigned quantity. I have now written a bit of test code comparing CTime and the ColeDateTime. /CtimeSpan combination. Whilst the values returned by the various member functions (year, month, etc,etc) all give identical values, the GetTime() and GetTotalSeconds() values differ by 3600 (1 hour) Here is my test code:-
// ----------------------- CTime operations -------------------------
CTime tNow;
tNow = CTime::GetCurrentTime();int iTimeYear = tNow.GetYear();
int iTimeMonth = tNow.GetMonth();
int iTimeDay = tNow.GetDay();
int iTimeHour = tNow.GetHour();
int iTimeMinute = tNow.GetMinute();
int iTimeSecond = tNow.GetSecond();unsigned long ulNow = tNow.GetTime();
// ----------- COleDateTime / CTimeSpan operations ----------
COleDateTime epoch(1970,1,1,0,0,0); // 1970 Jan 1 midnight
COleDateTime tCurrentTime;
tCurrentTime = COleDateTime::GetCurrentTime();int iOleYear = tCurrentTime.GetYear();
int iOleMonth = tCurrentTime.GetMonth();
int iOleDay = tCurrentTime.GetDay();
int iOleHour = tCurrentTime.GetHour();
int iOleMinute = tCurrentTime.GetMinute();
int iOleSecond = tCurrentTime.GetSecond();unsigned long ulOleTime = (unsigned long)(tCurrentTime-epoch).GetTotalSeconds();
Doug
-
I have an application in which time values are transferred byte-by-byte to an Arduino via USB/COM. I have now realised that using CTime objects will suffer from the 19 January 2038 problem where, after this date, GetTime() will return negative values due to the return value being signed. It appears that use of COleDateTime with CTimeSpan ::GetTotalSeconds will avoid this as the return value is an unsigned quantity. I have now written a bit of test code comparing CTime and the ColeDateTime. /CtimeSpan combination. Whilst the values returned by the various member functions (year, month, etc,etc) all give identical values, the GetTime() and GetTotalSeconds() values differ by 3600 (1 hour) Here is my test code:-
// ----------------------- CTime operations -------------------------
CTime tNow;
tNow = CTime::GetCurrentTime();int iTimeYear = tNow.GetYear();
int iTimeMonth = tNow.GetMonth();
int iTimeDay = tNow.GetDay();
int iTimeHour = tNow.GetHour();
int iTimeMinute = tNow.GetMinute();
int iTimeSecond = tNow.GetSecond();unsigned long ulNow = tNow.GetTime();
// ----------- COleDateTime / CTimeSpan operations ----------
COleDateTime epoch(1970,1,1,0,0,0); // 1970 Jan 1 midnight
COleDateTime tCurrentTime;
tCurrentTime = COleDateTime::GetCurrentTime();int iOleYear = tCurrentTime.GetYear();
int iOleMonth = tCurrentTime.GetMonth();
int iOleDay = tCurrentTime.GetDay();
int iOleHour = tCurrentTime.GetHour();
int iOleMinute = tCurrentTime.GetMinute();
int iOleSecond = tCurrentTime.GetSecond();unsigned long ulOleTime = (unsigned long)(tCurrentTime-epoch).GetTotalSeconds();
Doug
one hour difference between
CTimeandCOleDateTimeis becauseCOleDateTimeignores daylight saving time i would not care much about 2038, because today's code will be antique at that time if these time values will be shared across multiple devices then i would use CRT functionstime_t now = time(NULL);
-
one hour difference between
CTimeandCOleDateTimeis becauseCOleDateTimeignores daylight saving time i would not care much about 2038, because today's code will be antique at that time if these time values will be shared across multiple devices then i would use CRT functionstime_t now = time(NULL);
Hi Serkan, I thought that originally, but COleDateTime MUST be taking account of DST as the GetHour() function returns the correct value. Thinking about it overnight, I'm beginning to think that I should have applied DST when generating epoch - that would fit the symptoms, wouldn't it ? (The Arduino works with an unsigned quantity, so it will not be a problem !) After thought:- I now believe that the problem is due to taking the DIFFERENCE between Current Time and epoch (I actually got this code off the internet, but didn't do much thinking about it !!!) If DST is applied inherently to all OleDateTime objects, then taking the difference effectively removes any adjustment due to DST, So that would account for it for GetTime() and GetTotalSeconds() being 3600 seconds different !!
Doug
-
Hi Serkan, I thought that originally, but COleDateTime MUST be taking account of DST as the GetHour() function returns the correct value. Thinking about it overnight, I'm beginning to think that I should have applied DST when generating epoch - that would fit the symptoms, wouldn't it ? (The Arduino works with an unsigned quantity, so it will not be a problem !) After thought:- I now believe that the problem is due to taking the DIFFERENCE between Current Time and epoch (I actually got this code off the internet, but didn't do much thinking about it !!!) If DST is applied inherently to all OleDateTime objects, then taking the difference effectively removes any adjustment due to DST, So that would account for it for GetTime() and GetTotalSeconds() being 3600 seconds different !!
Doug
ColeDateTimestores a time stamp value without information about time zone and DST. It is up to you to know if the value is local time or UTC. If you useCOleDateTime::GetCurrentTimeto initialise it, it will hold a local time value. If you use the constructor or assignment operator accepting atime_tor_time64_tvalue, it will be UTC when thetime_tvalue has been retrieved usingtime()and not adjusted afterwards. If you need to store time stamp values for later use, store them as UTC. This avoids wrong values and simplifies calculation of time spans. If you need to display times as local times, perform the conversion just before display. See also Time Format Conversion Made Easy[^] here at CP. -
ColeDateTimestores a time stamp value without information about time zone and DST. It is up to you to know if the value is local time or UTC. If you useCOleDateTime::GetCurrentTimeto initialise it, it will hold a local time value. If you use the constructor or assignment operator accepting atime_tor_time64_tvalue, it will be UTC when thetime_tvalue has been retrieved usingtime()and not adjusted afterwards. If you need to store time stamp values for later use, store them as UTC. This avoids wrong values and simplifies calculation of time spans. If you need to display times as local times, perform the conversion just before display. See also Time Format Conversion Made Easy[^] here at CP.Hello Jochen, I was not aware that the timestamp obtained from COleDateTime would depend on how the object was initialised. Therefore in my test code the object epoch would result in a UTC value, whereas that obtained from the other object (which initialised via GetCurrentTime()) would be localtime. This then blows my "difference" explanation as to why the result from CTime is 3600 seconds different from the COleDateTimeSpan object. My Arduino code expects time quantities to be received as localtime (i.e. adjusted for DST)
Doug
-
Hello Jochen, I was not aware that the timestamp obtained from COleDateTime would depend on how the object was initialised. Therefore in my test code the object epoch would result in a UTC value, whereas that obtained from the other object (which initialised via GetCurrentTime()) would be localtime. This then blows my "difference" explanation as to why the result from CTime is 3600 seconds different from the COleDateTimeSpan object. My Arduino code expects time quantities to be received as localtime (i.e. adjusted for DST)
Doug
Still learning how to code wrote:
My Arduino code expects time quantities to be received as localtime (i.e. adjusted for DST)
You should change that to UTC if possible. When your Arduino uses a different time zone than your Windows system, the results would be wrong again.