EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: technix on May 30, 2017, 10:27:43 am
-
In my IoTv6 post someone mentioned the Year 2038 problem should be fixed alongside adding IPv6 capability to IoT systems. How do I investigate this?
-
Did you have a look at the usual suspects?
https://en.wikipedia.org/wiki/Year_2038_problem
-
Use uint32_t instead of a 32 bit integer and the problem will be one of your grandchildren.
-
Year 2106 (https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs) to be precise.
Use int64_t, so does linux.
-
For my unternal code maybe I can
typedef uint32_t time_t;or
typedef int64_t time_t;but what about the RTC hardware? The RTC hardware on STM32F1 is a 32-bit counter. While RTC on STM32F4 is implemented using a calendar.
-
You'd have to read the RTC datasheets to see how long they can run.
-
So here is the first challenge: make the internal RTC of STM32F1 year 2038 ready. Reference chip is STM32F103CBT6. (small package, very cheap)
-
Use a later epoch. I have an "MP4" player whose RTC starts counting at 2007-01-01.
-
So here is the first challenge: make the internal RTC of STM32F1 year 2038 ready. Reference chip is STM32F103CBT6. (small package, very cheap)
If it is a 32 bit counter then it is already 2038 ready. 2038 is only a problem if you use 31 bits (like in using an integer as a timestamp)!
-
So here is the first challenge: make the internal RTC of STM32F1 year 2038 ready. Reference chip is STM32F103CBT6. (small package, very cheap)
That is not a challenge. Just offset the timer.
The challenge is converting the 64 bit unix timestamps beyond 2038-01-19T03:14:07 into human readable form.
You C library can't do int64, right?
If it is a 32 bit counter then it is already 2038 ready. 2038 is only a problem if you use 31 bits (like in using an integer as a timestamp)!
That might be true. But you have to promote it to int64 anyway when you're doing calculations.
-
The C library is newlib which should be able to handle 64-bit time_t is I force it with
typedef int64_t time_t;in build time.
-
So here is the first challenge: make the internal RTC of STM32F1 year 2038 ready. Reference chip is STM32F103CBT6. (small package, very cheap)
If it is a 32 bit counter then it is already 2038 ready. 2038 is only a problem if you use 31 bits (like in using an integer as a timestamp)!
No, it is 20 years from now, so it is someone else's problem. While I probably dont die in 20 years, I certanly hope I will not be working here.
-
So here is the first challenge: make the internal RTC of STM32F1 year 2038 ready. Reference chip is STM32F103CBT6. (small package, very cheap)
If it is a 32 bit counter then it is already 2038 ready. 2038 is only a problem if you use 31 bits (like in using an integer as a timestamp)!
No, it is 20 years from now, so it is someone else's problem. While I probably dont die in 20 years, I certanly hope I will not be working here.
It would beme working on it - 24 now, 45 when the bug is triggered. :scared: :scared: :scared: :scared: :scared:
-
No, it is 20 years from now, so it is someone else's problem. While I probably dont die in 20 years, I certanly hope I will not be working here.
It would beme working on it - 24 now, 45 when the bug is triggered. :scared: :scared: :scared: :scared: :scared:
At the same company?
-
No, it is 20 years from now, so it is someone else's problem. While I probably dont die in 20 years, I certanly hope I will not be working here.
If your job is to make a product that will still be working in 20 years, it is your problem.
If the product lifetime is less than that and it won't be supported in 20 years, you can ignore it.
-
So here is the first challenge: make the internal RTC of STM32F1 year 2038 ready. Reference chip is STM32F103CBT6. (small package, very cheap)
If it is a 32 bit counter then it is already 2038 ready. 2038 is only a problem if you use 31 bits (like in using an integer as a timestamp)!
No, it is 20 years from now, so it is someone else's problem. While I probably dont die in 20 years, I certanly hope I will not be working here.
You are wrong. 2^32-1=4294967295 seconds. Divide that by 31557600 seconds in a year (with 365.25 days per year to account for a leap day every 4 years) and you get 136 years. 1970+136=2106
-
No, it is 20 years from now, so it is someone else's problem. While I probably dont die in 20 years, I certanly hope I will not be working here.
It would beme working on it - 24 now, 45 when the bug is triggered. :scared: :scared: :scared: :scared: :scared:
At the same company?
Probably not, but I will have to pick up the mess.