Daniele Nicolodi <daniele <at> grinta.net> writes:
On 10/04/2013 18:55, Riccardo De Maria wrote:
The library should handle correctly leap seconds, otherwise using unix time as a floating point number is already sufficient for many applications.
Please define what you mean by "handle correctly leap seconds".
I know they are not predictable but one can always update a file or the binary itself for the ones introduced over the years. I mentioned leap seconds because it is only feature that I see that has deep implication in the implementaion and that may be useful to people that needs to compute precise time delta between time stamped events or need to parse dates like 2012-06-30T23:59:60UTC. At the moment I use unix time since leap seconds would be a corner case for me that I can handle manually. Unix time can be converted from and to date string using datetime and pytz and this is needed only during io operations, can be used as coordinates in matplotlib plots without or with a trivial customized ticker, time deltas are just differences (although not always physically accurate), can be used as a timestamp (with glitches during the leap second). But please take this comment as suggestions, I only wanted to share my use case. Riccardo