Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 8041

MicroPython • Re: Pico GPS Date/Time server (no WiFi)

$
0
0
Your 'dom = t[2] - (( t[6] + 1) % 7) # Work out when Sunday was' intrigued me but does seem to work. At least up to year 2099. After that it fails, and gets increasingly incorrect.
It's quite simple one you look at it. Get the day of the week that the 31st falls on (0 = Monday, 6 = Sunday), add to make Monday = 1 and mod 7 to get Sunday = 0, subtract that from 31 to give the date of the Sunday.
Ah yes; that's a thing I'd forgotten - what day zero represents, whether zero is used at all.. At one point it was all over the place with 'time' and 'machine.RTC' methods, with a number of flawed conversions bugs. Trouble is everyone does it their own way -

Code:

 ISO standard    1=Mon, 6=Sat, 7=Sun Pico SDK        1=Mon, 6=Sat, 0=Sun MicroPython     0=Mon, 5=Sat, 6=Sun
I believe MicroPython is now compatible with Python though I recall even Python isn't entirely consistent. I think MicroPython may side-step some or all of those because it doesn't support all Python methods.

I usually use '0=Sunday' to be compatible with Pico SDK.
I assume the day of week must be failing after 2099 due to a bug in the time handling routines.
That's an interesting point. The error appears to be that 2100 is not a leap year but appears to be seen as such so -

Code:

    t = time.gmtime(time.mktime((year, 3, 31, 1, 0, 0, 0, 0)))# DST starts    s = t[2] - (( t[6] + 1) % 7) # Work out when Sunday was    t = time.gmtime(time.mktime((year, 10, 31, 1, 0, 0, 0, 0)))# DST ends    e = t[2] - (( t[6] + 1) % 7) # Work out when Sunday was    print("{} Mar {} - Oct {}".format(year, s, e))

Code:

2099 Mar 29 - Oct 25Correct2100 Mar 27 - Oct 30Should be Mar 28 - Oct 31
So is there a leap year bug in MicroPython, in 'time.mktime', 'time.gmtime', or elsewhere, or is it a bug in my own port of MicroPython which I may have been using which has screwed me over ?

It has all the hallmarks of using the simplistic "it's a leap year if year is divisible by four", forgetting "but not if divisible by 100, except if divisible by 400". That last 400 rule is what conveniently prevented a lot of flawed code using only the simplistic rule from breaking in 2000.

A quick check seems to suggest, if it's not a 'dom=' adjustment issue, it is a bug in vanilla MicroPython. I'm going to have to investigate further.

Update

Looks like a bug in MicroPython. The last item in the tuple printed from a Pico using vanilla MicroPython is 'day of year' and it appears it thinks there is a Feb 29 in 2100 when there isn't, that missing 'day 60'.

Code:

import timedef ShowDow(year, month, day):  t = time.gmtime(time.mktime((year, month, day, 1, 0, 0, 0, 0)))  print("{:04}-{:02}-{:02} {}".format(year, month, day, t))ShowDow(2100, 2, 22)ShowDow(2100, 2, 23)ShowDow(2100, 2, 24)ShowDow(2100, 2, 25)ShowDow(2100, 2, 26)ShowDow(2100, 2, 27)ShowDow(2100, 2, 28)ShowDow(2100, 3,  1)ShowDow(2100, 3,  2)

Code:

pi@Pi4B:~/apps/telnet $ mptool run utc-bug.pyRunning './utc-bug.py' on the device2100-02-22 (2100, 2, 22, 1, 0, 0, 0, 53)0 = Monday, correct2100-02-23 (2100, 2, 23, 1, 0, 0, 1, 54)1 = Tuesday, correct2100-02-24 (2100, 2, 24, 1, 0, 0, 2, 55)2100-02-25 (2100, 2, 25, 1, 0, 0, 3, 56)2100-02-26 (2100, 2, 26, 1, 0, 0, 4, 57)2100-02-27 (2100, 2, 27, 1, 0, 0, 5, 58)2100-02-28 (2100, 2, 28, 1, 0, 0, 6, 59)6 = Sunday, correct2100-03-01 (2100, 3, 1, 1, 0, 0, 1, 61)1 = Tuesday, wrong, should be Monday2100-03-02 (2100, 3, 2, 1, 0, 0, 2, 62)

Statistics: Posted by hippy — Fri Feb 27, 2026 11:02 pm



Viewing all articles
Browse latest Browse all 8041

Trending Articles