Epoch date/time is the same for all MCU's..?

[FeK9]

Morning All...

Been tinkering with getting time from Internet lately for my Pi Pico, and found a little curiosity....

One of the four MCU's differs in it's origin of Epoch...???

I tested these via Thonny IDE, with it's auto time sync off (sync_time = False) cold boot and no external RTC.

This is the format of the 8-tuple ( Year, Month, Day, DayOfWeek, Hour, Minute, Second, Sub Second ). I'm unsure
what the Sub Sec measure is (uS?).

Day of week by ISO 8601 standard starts on Monday and ends on Sunday, both the ESP32 and ESP8266 show a
week day no of '5' by ISO standard that's a Friday but the 1st January 2000 was Saturday. The Teensy 4.0 shows
a week day no of '3' by modern standard that's a Wednesday but the 1st of January 1970 was a Thursday, tho the
ISO 8601 standard didn't exist then....

The reason of Pi Pico Epoch is unclear, but it's Day of Week no '4' that's a Thursday, 1st of January this year was a Friday...

Got insight to Unix-Time and ISO 8601 standard from Wikipedia...

Curious...

Code: Select all

==================================

MicroPython v1.17 on 2021-09-02; ESP module with ESP8266
Type "help()" for more information.
>>> from machine import RTC
>>> rtc = RTC()
>>> rtc.datetime()
(2000, 1, 1, 5, 0, 0, 53, 636)          <<< Known Epoch used by MCU's and MicroPython >>>
>>> 

==================================

MicroPython v1.17 on 2021-09-02; ESP32 module with ESP32
Type "help()" for more information.
>>> from machine import RTC
>>> rtc = RTC()
>>> rtc.datetime()
(2000, 1, 1, 5, 0, 1, 8, 876935)        <<< Known Epoch used by MCU's and MicroPython >>>
>>>

==================================

MicroPython v1.17-138-gff4f1f3ab-dirty on 2021-11-10; Teensy 4.0 with MIMXRT1062DVJ6A
Type "help()" for more information.
>>> from machine import RTC
>>> rtc = RTC()
>>> rtc.datetime()
(1970, 1, 1, 3, 0, 1, 26, 325013)       <<< Known Epoch used by Unix/Linux >>>
>>> 

==================================

MicroPython v1.17 on 2021-09-02; Raspberry Pi Pico with RP2040
Type "help()" for more information.
>>> from machine import RTC
>>> rtc = RTC()
>>> rtc.datetime()
(2021, 1, 1, 4, 0, 1, 23, 0)            <<< Unknown Epoch ????             >>>
>>>

==================================

[pythoncoder]

I raised this last February. I find it bizarre, but Dave Hylands shows a neat way to work round this.

[FeK9]

I raised this last February. I find it bizarre, but Dave Hylands shows a neat way to work round this.

Is odd, did find "Raspberry Pi Pico C/C++ SDK" 269 page Pdf document...

Page 163 paragraph '4.1.19. hardware_rtc' comments made in the code indicate that Sunday is the start of the week at no. '0' and
ends at no. '6' which is Saturday, must be a C++ thing...

All four MCU's are still a week day short, it's a curious thing...

Will continue research on the side, out of interest sake...

[mattyt]

As an aside...for a long time, Damien has been considering changing to the 1970 the epoch - for all ports - bringing it in-line with CPython (rather than the year 2000). It's a complex topic and, since it will be a breaking change, has to be very carefully considered. Some discussion is in #5969.

[FeK9]

As an aside...for a long time, Damien has been considering changing to the 1970 the epoch - for all ports - bringing it in-line with CPython (rather than the year 2000). It's a complex topic and, since it will be a breaking change, has to be very carefully considered. Some discussion is in #5969.

Thanks @mattyt

The GitHub link made for a interesting read, here's my two cents worth...

Going back to 1970 Epoch...
Pro and con's

To be more complaint with CPython..?
+1

32bits will roll over in Jan 2038...

It's not in conceivable that many scientific industrial or other embedded applications using MP will still be in use in 2038, and more than likely never been update in it's life... It's highly likely in some instances the probably expensive device will malfunction in some manner.
Not good....
-1

Going BigInt 64bit...?

It would fix the Roll over problem, you could count the seconds till the end of time figuratively speaking. But one would be using more resources like cpu time and memory, and probably breaking a good few modules/libraries a long the way... Not to mention perplexion and ticking off the few developers and maintainer...
-1 -1 -1

https://en.wikipedia.org/wiki/Year_2038_problem

Now for the 2000 Epoch...

From my limited understanding most if not all the core of MP and it's modules/libraries would be quite happy with a Epoch of 2000. Using 32bits the next Roll over would be in 2068, by then I suspect the youngster's to be would be tinkering with Qbits...
+10 -1

======

On a side note I found where the odd Epoch of the Pi Pico comes from, and from the comments on the of listing Monday '0' is the start of the week...

[dhylands]

Micropython small ints allow for 30 bits of positive value, which translates to about 34 years, so a 2000 epoch gets you years from 1966 thru to 2034.

So I think that the 2000 epoch was chosen to allow dates & times to still be used with small ints.

[FeK9]

Micropython small ints allow for 30 bits of positive value, which translates to about 34 years, so a 2000 epoch gets you years from 1966 thru to 2034.

So I think that the 2000 epoch was chosen to allow dates & times to still be used with small ints.

Either way, roll over is closer than it should be...

[hippy]

The reason of Pi Pico Epoch is unclear, but it's Day of Week no '4' that's a Thursday, 1st of January this year was a Friday...

There were a number of issues with MicroPython on a Pico translating data between one representation and others. Don't know if any have been fixed -

viewtopic.php?f=21&t=11108

[FeK9]

The reason of Pi Pico Epoch is unclear, but it's Day of Week no '4' that's a Thursday, 1st of January this year was a Friday...

There were a number of issues with MicroPython on a Pico translating data between one representation and others. Don't know if any have been fixed -

viewtopic.php?f=21&t=11108

Morning hippy...

I made an error / assumption on my first post, been a regular Joe and having a picture of a calendar in my mind
the week started on a Sunday. My second error was starting the count from one. The 'day of week' for all four
RTC tuples are correct... My Oop's...

With many hours of scratching the net I discovered ISO 8601 and Mod 7... What complicated things for me was
a early edition and latest of "Raspberry Pi Pico C/C++ SDK" manual, there week started on Sunday with '0'. Even had
a passing look at 'Hardware Errata' for the RP2040... I finally had a look at the MP source code for the Pi Pico on
GitHub and found the 2021 Epoch Year...

[bulletmark]

Micropython small ints allow for 30 bits of positive value, which translates to about 34 years, so a 2000 epoch gets you years from 1966 thru to 2034.

Actually that's an unsigned value 2^30 = 34 years which is epoch 2000 to 2034. Not sure where you got the 1966 (-34) from?