micropython
asctime in logging will never output because strftime is not an attribute of time
Expexted behaviour:
Using this formatter the log output will include a timestamp.
logging.Formatter('%(asctime)s | %(name)s | %(levelname)s - %(message)s')
Like this:
Tue Feb 17 09:42:58 2009 | MAIN | INFO - test
Actual behaviour:
Timestamp will always be None
None | MAIN | INFO - test
Cause:
The formatTime() method checks for the strftime attribute, which does not exist in the Micropython implementation:
def formatTime(self, datefmt, record):
if hasattr(time, "strftime"):
return time.strftime(datefmt, time.localtime(record.ct))
return None
To support time.strftime you need to install the time module extension, eg using:
mpremote mip install time
Perhaps this should be added as a dependency for logging?
I guess it's optional behaviour though, a comment in the code along these lines might be more suitable
Interesting. I didn't think there was an separate time package given that there's already time in the standard image. The micropython-lib version only implements strftime, is there a specific reason to split the packages up like that?
Interesting. I didn't think there was an separate time package given that there's already time in the standard image. The micropython-lib version only implements strftime, is there a specific reason to split the packages up like that?
@DracoTomes In order to keep firmware size down, we provide the most common / most useful stuff by default. Then we provide optional extras.
Really we should rename micropython-lib's time to time-strftime to indicate that it's an extension package that just adds strftime to time. (See the very last paragraph of https://github.com/micropython/micropython-lib/#notes-on-terminology).
Perhaps this should be added as a dependency for logging?
For similar reasons, I think it should be optional. But yes, documentation/comment would definitely be a good idea.
That was my assumption as well, good to know. Coming at this as a new user documentation/rename would definitely be welcome.
Should I close this Issue now, given there's not actually anything wrong or should I leave this open to reference for a future commit?