ariebovenberg / whenever

⏰ Modern datetime library for Python, available in Rust or pure Python
https://whenever.rtfd.io
MIT License
831 stars 13 forks source link

can 'timestamp()' be changed from 'float' to 'int'? #63

Closed bxparks closed 2 months ago

bxparks commented 7 months ago

https://whenever.readthedocs.io/en/latest/api.html#whenever.AwareDateTime

If we are breaking free of the standard datetime library, then I have to ask: Does the AwareDateTime.timestamp() function need to return the epoch_seconds as a float? Must we preserve backwards compatibility with Python's time.time(), or can it be changed to int instead, like all other datetime libraries that I am aware of?

bxparks commented 7 months ago

Answering my own question: It needs to be a float because AwareDateTime provides microsecond resolution. It could change to int if the value was interpreted as "microseconds since UNIX epoch".

ariebovenberg commented 7 months ago

If we are breaking free of the standard datetime library

This is the key question. When I added this method, I was still of the mind "don't break too much", but now I believe that breaking is a better strategy in the long term.

Continuing on this line, I'd also like to go for nanosecond resolution (like other modern libraries).

This means the timestamp methods could be available in epoch_seconds, epoch_millis, epoch_nanos etc.

bxparks commented 7 months ago

I like epoch_seconds(), epoch_millis(), epoch_nanos(). I always have to look up what "timestamp" means in the Python world.

The problem with nanosecond resolution is that an i64 has a range of only +/- 292.27 years, which isn't enough to handle 4-digit years.

ariebovenberg commented 7 months ago

Python's int of course doesn't have that limit—but this may be a problem when implementing this in an extension module.

bxparks commented 7 months ago

Doesn't CPython gain some efficiency using machine native sized integers, rather than arbitrary precision int? (Not an expert on CPython internals). I was also considering efficiency issues if/when whenever is ported to MicroPython.

ariebovenberg commented 7 months ago

Agree that it's probably best to stick to native sized integers where possible. The only solution I can imagine now is to raise OverflowException and clearly document it.

ariebovenberg commented 4 months ago

In combination with #91 , it looks like this is definitely going to happen. In implementing the extension I realized that float just isn't precise enough to handle timestamps up to full microsecond (let alone nanosecond)

ariebovenberg commented 2 months ago

Release 0.6.0 is now out with this change.