datetime porting proposal

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
Post Reply
User avatar
lorcap
Posts: 10
Joined: Sat May 23, 2020 9:02 am
Location: Italy

datetime porting proposal

Post by lorcap » Sun Sep 19, 2021 8:31 pm

Hi everyone,

my long-term goal is converting my personal project from Zerynth to MicroPython. First step would be porting the datetime module I wrote last year. It represents a minimalist implementation of Python module datetime. Is anybody working on something similar?

What would be a good name, datetime or udatetime? Despite what the doc says, I see the u version is not used under `micropython-lib/micropython-lib/`.

Thanks,
Lorenzo

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: datetime porting proposal

Post by pythoncoder » Wed Sep 22, 2021 8:43 am

This looks useful and it should be easy to port. But the GNU licensing will limit its use.
Peter Hinch
Index to my micropython libraries.

User avatar
lorcap
Posts: 10
Joined: Sat May 23, 2020 9:02 am
Location: Italy

Re: datetime porting proposal

Post by lorcap » Thu Sep 23, 2021 9:38 pm

Thanks Peter for you reply.

I'm almost done with the porting. It was easy and I managed to improve the library. For a glimpse, see my github repo.

Regarding the licensing, I don't mind adopting the MIT License.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: datetime porting proposal

Post by pythoncoder » Fri Sep 24, 2021 1:32 pm

I am not a lawyer but I'm pretty sure you can't legally do this. People contributing to (MIT licenced) MicroPython have to guarantee that their code is not derived from GPL sources. The GPL has a horrible reputation.
Peter Hinch
Index to my micropython libraries.

User avatar
lorcap
Posts: 10
Joined: Sat May 23, 2020 9:02 am
Location: Italy

Re: datetime porting proposal

Post by lorcap » Fri Sep 24, 2021 3:47 pm

I am the author of the that code and as such I can choose and change the licensing model (I believe).

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: datetime porting proposal

Post by pythoncoder » Sat Sep 25, 2021 7:15 am

Ah, I'd missed that you wrote the original. I'm sure you're right about that :D
Peter Hinch
Index to my micropython libraries.

User avatar
lorcap
Posts: 10
Joined: Sat May 23, 2020 9:02 am
Location: Italy

Re: datetime porting proposal

Post by lorcap » Sun Sep 26, 2021 8:57 pm

Ok, I just made my pull requests for code (#449) and doc (#7859).

User avatar
mattyt
Posts: 410
Joined: Mon Jan 23, 2017 6:39 am

Re: datetime porting proposal

Post by mattyt » Mon Sep 27, 2021 12:12 am

I'll try and find time to review these properly; datetime is an often-requested feature and this will be a wonderful addition to MicroPython. Thank-you!

User avatar
lorcap
Posts: 10
Joined: Sat May 23, 2020 9:02 am
Location: Italy

Re: datetime porting proposal

Post by lorcap » Mon Sep 27, 2021 9:03 am

Thanks for your interest, much appreciated.

As stated in the documentation I wrote for the module, the two main constraints for `timedelta` type are:
  • Minimum resolution is 1 second, instead of 1 microsecond.
  • Maximum delta spans over ±24855 days (±2^31 seconds or ±68 years) instead of ±999999999 days.
Both constraints allow `timedelta` to be simple: it can be represented with a single `int()`.

BTW, am I right when I say that MicroPython holds an `int()` within an `int32_t` (at least on 32 target boards)? Zerynth sacrificed one bit to signal that the Python type could be represented with a plain `int32_t`. Hence, an `int()` was in the range ±2^30 (i.e., ±34 years). MicroPython looks different to me, at least for the unix port, and I extended the range to ±2^31 (±68 years). Or is this micro-optimization futile, after all?

Not having to deal with microseconds also changes the constructor interface from `timedelta(days=0, seconds=0, microseconds=0, milliseconds=0, minutes=0, hours=0, weeks=0)` to `timedelta(self, hours=0, minutes=0, seconds=0, days=0, weeks=0)`. A different approach would be to keep the same Python arguments and discard any microsecond juggling.

`datime()` is again an `int()` of days since January 1st, 0001, plus a `timedelta()`. Hence, arithmetic between `datetime()`'s and `timedelta()`'s are limited to ±68 years. On the other hand, no limits to datetime/datetime arithmetic.

Python's classes `time()` and `date()` were not implemented: `date()` can be a `datetime()` set to midnight; `time()` can be a `timedelta()` in the range [0-24h). Providing `date()` and `time()` constructors wouldn't be difficult, if needed.

`timezone()` requires user customization for dealing with timezones: no IANA timezones were implemented which were demanded to another module `dateutil.tz` even in Python. Folding (to resolve wall-time ambiguities during DST changes) is not implemented.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: datetime porting proposal

Post by pythoncoder » Fri Nov 05, 2021 5:48 pm

In a rather belated response to your query, this doc explains the small integer mapping. It uses 31 bits.
Peter Hinch
Index to my micropython libraries.

Post Reply