-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
Fix documentation of epoch/time.time #88035
Comments
The descriptions for the following:
indicate that it is platform dependent. However, that is likely untrue. See the brief discussion here: DataDog/integrations-core#6692 (comment) |
On Windows 10 (build 20H2), I get: Python 3.10.0a7+ (heads/master:b136b1aac4, Apr 16 2021, 14:36:39) [MSC v.1928 64 bit (AMD64)] on win32
>>> import time
>>> time.gmtime(0)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0) |
time.time doc says "On Windows and most Unix systems, the epoch is January 1, 1970, 00:00:00 (UTC)" The epoch doc says "For Unix, the epoch is January 1, 1970, 00:00:00 (UTC)". At least, the epoch doc can be completed to also mention that it's the same on Windows. |
"platform dependent" was added in 2017 by the commit (bpo-29026): commit 23557d5
--- MS-DOS (no longer supported by Python since 2014) uses 1980-01-01 epoch. The Windows FILETIME type uses 1601-01-01 epoch. Python has convention functions to the Unix 1970-01-01 Epoch: static __int64 secs_between_epochs = 11644473600; /* Seconds between 1.1.1601 and 1.1.1970 */ static void
FILE_TIME_to_time_t_nsec(FILETIME *in_ptr, time_t *time_out, int* nsec_out)
{
/* XXX endianness. Shouldn't matter, as all Windows implementations are little-endian */
/* Cannot simply cast and dereference in_ptr,
since it might not be aligned properly */
__int64 in;
memcpy(&in, in_ptr, sizeof(in));
*nsec_out = (int)(in % 10000000) * 100; /* FILETIME is in units of 100 nsec. */
*time_out = Py_SAFE_DOWNCAST((in / 10000000) - secs_between_epochs, __int64, time_t);
}
void
_Py_time_t_to_FILE_TIME(time_t time_in, int nsec_in, FILETIME *out_ptr)
{
/* XXX endianness */
__int64 out;
out = time_in + secs_between_epochs;
out = out * 10000000 + nsec_in / 100;
memcpy(out_ptr, &out, sizeof(out));
} More epochs for more fun: |
Seen that no one is working on this issue I created an PR to clarify the docs. |
I was going to close the change, but I had a last look and... oh... I found that the Python test suite checks that the Epoch is 1970-01-01 at 00:00 since 2008! I wrote #74849 to add an explicit test and I updated the doc. |
The epoch is `January 1st, 1970 on all platforms`, according to python#88035
Follow #88035, update doc-string of epoch in timemodule.c The epoch is `January 1st, 1970 on all platforms`, according to current documentation.
…H-118076) Follow pythonGH-88035, update doc-string of epoch in timemodule.c The epoch is `January 1st, 1970 on all platforms`, according to current documentation. (cherry picked from commit 7c6cc00) Co-authored-by: lit <litlighilit@foxmail.com>
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
epoch
in timemodule.c #118076epoch
in timemodule.c (GH-118076) #118097The text was updated successfully, but these errors were encountered: