Timestamp to human readable date&time string (Martin Poloch home assignment) #1535
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,9 @@ | ||
| import utime | ||
|
|
||
| if False: | ||
| from typing import Tuple | ||
|
|
||
|
|
||
| def format_amount(amount: int, decimals: int) -> str: | ||
| if amount < 0: | ||
| amount = -amount | ||
|
|
@@ -64,3 +70,57 @@ def format_duration_ms(milliseconds: int) -> str: | |
| divisor = 1 | ||
|
|
||
| return format_plural("{count} {plural}", milliseconds // divisor, unit) | ||
|
|
||
|
|
||
| def _calculate_timestamp_correction(timestamp: int) -> (Tuple[tuple, int]): | ||
| """ | ||
| utime module can't convert timestamp to datetime with seconds precision. | ||
| returns date in tuple format and correction in seconds | ||
| from the utime-calculated date's midnight | ||
| to the correct datetime | ||
| Example: | ||
| timestamp 1616057224 | ||
| correct datetime "2021-03-18 08:47:04" | ||
| utime-calculated datetime "2021-03-18 08:46:56" | ||
| midnight datetime "2021-03-18 00:00:00" | ||
| returned date (2021, 3, 18, 0, 0, 0, 3, 77, 0) | ||
| correction 31624 (~ 8:47:04) | ||
| """ | ||
| approx_datetime = utime.localtime(timestamp) | ||
|
There was a problem hiding this comment. On the actual device this fails with: There was a problem hiding this comment. Even if we got this working, I suspect that it might give an incorrect time on the device, because the STM32 implementation seems to be using 2000-01-01 as the beginning of the epoch as opposed to the UNIX implementation which uses 1970-01-01. It's hard to believe, but that's what I see in the C code. I didn't actually test. There was a problem hiding this comment. Yes, from my limited sources, I expect the behavior you described. Sorry for not mentioning it in the PR description. There was a problem hiding this comment. If the two implementations are really using different epochs, then I have doubts whether we should be using Secondly, there is #741, which indicates that there may have been some opposition to adding the utime module to the firmware build. There was a problem hiding this comment. I just added PR #1548 to update uPy to 1.14 - among other things it introduces There was a problem hiding this comment. fwiw #741 is not opposed to adding utime, but adding full python's |
||
| # filter date only, erase time | ||
| date = approx_datetime[:3] + (0, 0, 0) + approx_datetime[6:] | ||
| # get timestamp corresponding to time 0:00:00 | ||
| first_daily_timestamp = utime.mktime(date) | ||
| # calculate correction of the midnight timestamp to the origiral | ||
| correction = timestamp - first_daily_timestamp | ||
|
Comment on lines
+93
to
+95
There was a problem hiding this comment. The "correction" can be calculated more simply by taking |
||
|
|
||
| return date, correction | ||
|
|
||
|
|
||
| def format_timestamp_to_human(timestamp: int) -> str: | ||
| """ | ||
| Returns human-friendly representation of a unix timestamp (in seconds format). | ||
| Minutes and seconds are always displayed as 2 digits. | ||
| Example: | ||
| >>> format_timestamp_to_human(0) | ||
| '1970-01-01 00:00:00' | ||
| >>> format_timestamp_to_human(1616051824) | ||
| '2021-03-18 07:17:04' | ||
| """ | ||
| date, correction = _calculate_timestamp_correction(timestamp) | ||
| # negative correction = substract 12 hours and calculate again | ||
| if correction < 0: | ||
| date, correction = _calculate_timestamp_correction(timestamp - 43_200) | ||
| correction += 43_200 | ||
andrewkozlik marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| # create precise datetime by adding the correction datetime to date | ||
| correction_tuple = utime.localtime(correction) | ||
| precise_datetime = date[:3] + correction_tuple[3:6] | ||
|
|
||
| return "{}-{:02d}-{:02d} {:02d}:{:02d}:{:02d}".format( | ||
| precise_datetime[0], # year | ||
| precise_datetime[1], # month | ||
| precise_datetime[2], # mday | ||
| precise_datetime[3], # hour | ||
| precise_datetime[4], # minute | ||
| precise_datetime[5], # second | ||
| ) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this problem occurs only in the UNIX implementation, because micropython quite pointlessly converts the timestamp to a C
floatwhich has a mantissa of 23 bits, causing the lower bits to get lost. The STM32 implementation reads it as an integer.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually fixed upstream.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we need to merge MicroPython 1.14 in before merging in this PR - #1548