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.
