> 1. For the reasons presented, I think it's worth attempting to define > a common API that is based on datetime, but is tailored towards high > precision time operations (at least using a different internal > representation, perhaps supporting TAI). IIUC, the concern is about the DB-API, which does sort-of mandate that the datetime module is used to represent SQL time types. So not basing this off datetime isn't really an option. Providing a subtype should work, though. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4