-
-
Notifications
You must be signed in to change notification settings - Fork 18.5k
ENH: Add unixtime accessor to Timestamp and DatetimeIndex objects #43975
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
Comments
maybe +0.25 for this, would take a PR implementing it. use |
Thanks Jeff, I wouldn't object to epochtime, but epoch is something of a generic word, and the "obvious" epoch can be field dependent. For example, most astronomers would say epoch time begins on 2000-01-01, or even 1950-01-01. unixtime is less ambiguous. |
This this the same request as #14772? |
@mroeschke, yes, that does look similar. I didn't find it in my original search. I'm guessing the fact that the other ticket has been inactive since 2019 should be taken as an indication of its priority... |
Thanks, going to close as a duplicate of #14772 As pandas is a volunteer project, features get implemented from the community instead of priority. |
Pain Point
I feel that extracting unixtimes from date strings is less graceful than it could be, and relies on the user knowing more about the internal format of datetime objects than they should have to.
Currently (at least as of version 1.3.3), a user needs to cast a Timestamp object as an integer to extract the unixtime (in nanoseconds)
This makes sense if you understand how a Timestamp object is storing its information internally. However, I would argue that this requires the end-user to understand an implementation detail that they shouldn't need to. I shouldn't need to care whether the time is represented internally by unixtime, TAI, GPS time etc. I should be able to ask for unixtime without relying on knowledge of the implementation details.
I would also argue that the current approach also makes code harder to read. While other attributes of time can be obtained by asking for them directly, unixtime requires an more indirect request
To add to the confusion, the
DatetimeIndex
object requires the user needs to useview
instead ofastype
(see #38544). I don't understand quite why the interface for Timestamps and DatetimeIndices needs to be different .Proposed solution
Timestamps and DatetimeIndex objects should have a unixtime accessor consistent with the interface used to access hour of day, day of month, etc.
The accessor should return a floating point number for a timestamp, or an iterable (e.g a Series) of floating point numbers for a DatetimeIndex. This float should represent the number of seconds elapsed from the epoch. The unit should be seconds, not nanoseconds, to be consistent with the definition of unixtime (https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_16).
API breaking implications
This will not break any other features of the API, although deprecating the astype() and view() accessors could be considered. If these accessors are deprecated, that would make changing the internal representation in a Timestamp object easier in future.
Describe alternatives you've considered
The current methods work, although they are unsatisfactory because
The text was updated successfully, but these errors were encountered: