asctime in logging will never output because strftime is not an attribute of time

[DracoTomes]

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

[dpgeorge]

To support time.strftime you need to install the time module extension, eg using:

mpremote mip install time

[andrewleech]

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

[DracoTomes]

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?

[jimmo]

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.

[DracoTomes]

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?