Feature/calendar #521
Feature/calendar #521
Conversation
|
Nice work pulling this together! On a structural note, the CI "Check code formatting / build (pull_request)" should normally be resolved by running Similarly eventually could you split the work into 3 commits - one for each package? There's a particular git commit format used here, hopefully it'll be easy enough to see from the git log: https://github.com/micropython/micropython-lib/commits/master I'll take a look at the code properly when I've got a little more time :-) |
Thanks Andrew for the extra details. Aiming to get back to this soon to correct the formatting. I was looking at how to break it into 3 commits as there are dependencies between the packages. I could update unittest first, then datetime, then calendar can go in. |
|
Yeah no worries. To be clear they don't need to be separate PR's, separate commits on this branch is fine! |
|
|
||
|
|
||
| # Constants for months referenced later | ||
| January = 1 |
There was a problem hiding this comment.
It's a good idea to apply micropython.const() to const values
| return spacing.join(c.center(colwidth) for c in cols) | ||
|
|
||
|
|
||
| EPOCH = 1970 |
There was a problem hiding this comment.
This could be a problem; on some ports the epoch is 1970, others it's 2000.
Read Damien's summary and micropython/micropython#6873 for background.
Should be able to use something like time.gmtime(0)[0] to retrieve the epoch year.
There was a problem hiding this comment.
At the moment, the EPOCH is only used for calendar.timegm(tuple) to calculate the Unix timestamp. I believe this needs to stay as 1970 so the calculated seconds match expectations. (do we have data size or resolution issues?) I get a different number of seconds for the result using the same date/time when testing against Python running on Ubuntu compared to the M5stack and the EPOCH manually set to 1970. (I want to retest to confirm)
I could move the EPOCH values into the function, so it isn't visible to users of Calendar and can't be misused for systems with an EPOCH of 2000. If timegm() is not a required function, we could remove it from Calendar.
933faee to
8068bc3
Compare
Committing a baseline of the code from cPython before making any suybstantial changes.
Base on cpython calendar functions. This provides most calendar functions. It does not support locales and some command line options used to create text calendars.
Added strftime to support new calendar module. strftime does not support all formatting options. Only enough required for calendar.
Added assertRaisesRegex and assertCountEqual to support testing the calendar module.
8068bc3 to
e73644b
Compare
No description provided.