CMonthCalCtrlDlg and the 2038 problem
-
I have a heating control application that is based on some C++ code and some Arduino code. Having "woken up" to the 2038 timebomb, I am currently converting my code to cope with this (even though I shall in all probablity be "pushing up the daisies" by then !! ). As I believe Arduino uses 32 bit unsigned time variables, I believe it is OK after 2038 I am running MSVC 6.0 and, being of limited means, do not want to upgrade to 7.0 (or higher ) which I believe introduces a 64-bit version of the CTime class whicjh will cope with the situation. Having discovered an alternative solution ( Time64 - 64 bit Times for 32 bit Windows Apps[^] )I am doing this by abandoning CTime and replacing the code with 64-bit variables and using system calls. However, does anybody know if the MFC class CMonthCalCtrl is susceptible to the 2038 problem (as it DOES use CTime objects as parameters to it's functions) or am I 2038-safe by only employing calls using the SYSTEMTIME parameter ? I could test this but thought that I would ask the experts anyway!! Any help appreciated !
-
I have a heating control application that is based on some C++ code and some Arduino code. Having "woken up" to the 2038 timebomb, I am currently converting my code to cope with this (even though I shall in all probablity be "pushing up the daisies" by then !! ). As I believe Arduino uses 32 bit unsigned time variables, I believe it is OK after 2038 I am running MSVC 6.0 and, being of limited means, do not want to upgrade to 7.0 (or higher ) which I believe introduces a 64-bit version of the CTime class whicjh will cope with the situation. Having discovered an alternative solution ( Time64 - 64 bit Times for 32 bit Windows Apps[^] )I am doing this by abandoning CTime and replacing the code with 64-bit variables and using system calls. However, does anybody know if the MFC class CMonthCalCtrl is susceptible to the 2038 problem (as it DOES use CTime objects as parameters to it's functions) or am I 2038-safe by only employing calls using the SYSTEMTIME parameter ? I could test this but thought that I would ask the experts anyway!! Any help appreciated !
Member 13459733 wrote:
I am running MSVC 6.0 and, being of limited means, do not want to upgrade to 7.0 (or higher ) which I believe introduces a 64-bit version of the CTime class...
Visual C++ .NET 2002 (a.k.a., MSVC++ 7) was strictly 32-bit. Have you considered Visual Studio Community 2017? It's fee structure might be more accommodatable to you.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
I have a heating control application that is based on some C++ code and some Arduino code. Having "woken up" to the 2038 timebomb, I am currently converting my code to cope with this (even though I shall in all probablity be "pushing up the daisies" by then !! ). As I believe Arduino uses 32 bit unsigned time variables, I believe it is OK after 2038 I am running MSVC 6.0 and, being of limited means, do not want to upgrade to 7.0 (or higher ) which I believe introduces a 64-bit version of the CTime class whicjh will cope with the situation. Having discovered an alternative solution ( Time64 - 64 bit Times for 32 bit Windows Apps[^] )I am doing this by abandoning CTime and replacing the code with 64-bit variables and using system calls. However, does anybody know if the MFC class CMonthCalCtrl is susceptible to the 2038 problem (as it DOES use CTime objects as parameters to it's functions) or am I 2038-safe by only employing calls using the SYSTEMTIME parameter ? I could test this but thought that I would ask the experts anyway!! Any help appreciated !
The MFC
CMonthCalCtrlclass is just a wrapper for the corresponding Windows system control. You might also have a look at the MFC sources (winctrl5.cpp) which are usually installed with Visual Studio. Then you will see that the class just sends messages usingSYSTEMTIMEparameters. The functions acceptingCTimeandCOleDateTimeparameters will convert those toSYSTEMTIME. So you have to check the documentation for the used types:About Month Calendar Controls (Windows)[^]:
Note Windows does not support dates prior to 1601. See FILETIME for details. The month-calendar control is based on the Gregorian calendar, which was introduced in 1753. It will not calculate dates that are consistent with the Julian calendar that was in use prior to 1753.
SYSTEMTIME structure (Windows)[^]:
wYear The year. The valid values for this member are 1601 through 30827.
COleDateTimeuses the DATE Type | Microsoft Docs[^] internally. For CTime see also the source (atltime.h). The oldest version I have here is VS 2003 (MSVC 7.1) which already uses__time64_t. Result: If you still want to use software from the last millenium to handle dates beyond 2038 you can use theCMonthCalCtrlwhen using only functions that acceptSYSTEMTIMEandCOleDateTimeparameters. -
The MFC
CMonthCalCtrlclass is just a wrapper for the corresponding Windows system control. You might also have a look at the MFC sources (winctrl5.cpp) which are usually installed with Visual Studio. Then you will see that the class just sends messages usingSYSTEMTIMEparameters. The functions acceptingCTimeandCOleDateTimeparameters will convert those toSYSTEMTIME. So you have to check the documentation for the used types:About Month Calendar Controls (Windows)[^]:
Note Windows does not support dates prior to 1601. See FILETIME for details. The month-calendar control is based on the Gregorian calendar, which was introduced in 1753. It will not calculate dates that are consistent with the Julian calendar that was in use prior to 1753.
SYSTEMTIME structure (Windows)[^]:
wYear The year. The valid values for this member are 1601 through 30827.
COleDateTimeuses the DATE Type | Microsoft Docs[^] internally. For CTime see also the source (atltime.h). The oldest version I have here is VS 2003 (MSVC 7.1) which already uses__time64_t. Result: If you still want to use software from the last millenium to handle dates beyond 2038 you can use theCMonthCalCtrlwhen using only functions that acceptSYSTEMTIMEandCOleDateTimeparameters.Quote:
If you still want to use software from the last millenium to handle dates beyond 2038 you can use the CMonthCalCtrl when using only functions that accept SYSTEMTIME and COleDateTime parameters.
I had thought that that MIGHT be the case and seems like a good solution for me ! Thank you !