-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ParseDate has the less common date format listed first #154
Comments
I'll look into it @b-jazz. But to be fair: those messages are marked "debug" for a reason, maybe you can adjust the logging level on your side. Or is there something important that you would miss (haven't checked the levels in quite some time)? |
Completely fair. I considered turning down logs for that module, but thought the debug message might not be very useful if both formats exist and it only logs an error on the more common case. I'm not opposed to closing this out without changing anything. Just wanted to bring some light to it. |
The only logging that osmapi.dom does is that message. So it is safe to just config it out on my side. |
If this logs are raised with standard operation of OSM API then these messages are a pure noise, and getting rid of them would help. Though maybe asking to unify this timestamps in OSM API would make sense? |
There are a lot of libraries that add such "noise", the debug messages are mainly meant for debugging. So if you want to get rid of these messages, simply set a different log level for logging.getLogger(osmapi.dom.__name__).setLevel(logging.INFO) I added a quick example script to show how to configure the logger |
I get a lot of log spam in my logs about dates not matching the format string. Upon looking into it the code and the API specs, it looks like the order of formats could be reversed and the amount of log spam could be reduced. It appears that the /api/0.6/notes endpoint generates the "UTC" format, while the rest of the api endpoints generate ISO-8601 (2023-10-24T21:20:27Z) format dates.
The cleaner, slightly more complex solution would to not log an error unless both formats fail to match anything.
The text was updated successfully, but these errors were encountered: