[issue28148] [Patch] Also stop using localtime() in timemodule

Changes by Donald Stufft : -- pull_requests: +993 ___ Python tracker ___ ___

[issue28148] [Patch] Also stop using localtime() in timemodule

Changes by Alexander Belopolsky : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker

[issue28148] [Patch] Also stop using localtime() in timemodule

Roundup Robot added the comment: New changeset 3afad465b3e1 by Alexander Belopolsky in branch '3.6': Issue #28148: Added a NEWS entry. https://hg.python.org/cpython/rev/3afad465b3e1 -- ___ Python tracker

[issue28148] [Patch] Also stop using localtime() in timemodule

Roundup Robot added the comment: New changeset c81b9107ec42 by Alexander Belopolsky in branch '3.6': Issue #28148: Stop using localtime() and gmtime() in the time module. https://hg.python.org/cpython/rev/c81b9107ec42 -- nosy: +python-dev ___ Python

[issue28148] [Patch] Also stop using localtime() in timemodule

Changes by Antoine Pitrou : -- nosy: -pitrou ___ Python tracker ___ ___ Python-bugs-list

[issue28148] [Patch] Also stop using localtime() in timemodule

Alexander Belopolsky added the comment: > I thought `[...]localtime_r()`'s way of ordering the arguments made most > sense here. Right. I keep forgetting which one is localtime_r and which is localtime_s. I don't think there is any preference in the Python codebase. (PEP 8 is silent on this

[issue28148] [Patch] Also stop using localtime() in timemodule

Ed Schouten added the comment: I've been brainwashed by https://google.github.io/styleguide/cppguide.html#Function_Parameter_Ordering over the last couple of years, which is why I thought `localtime()/localtime_r()`'s way of ordering the arguments made most sense here. ;-) --

[issue28148] [Patch] Also stop using localtime() in timemodule

Alexander Belopolsky added the comment: I see that you picked localtime_s-like order of arguments. While I have no personal preference, I wonder why you prefer output to follow input. The usual UNIX/C convention is the opposite. Interfaces like sprintf, strcat, strftime and many other have

[issue28148] [Patch] Also stop using localtime() in timemodule

Alexander Belopolsky added the comment: Very nice. I'll give it a week or two for the others to chime in and commit if I don't hear any objections. -- keywords: +patch stage: patch review -> commit review versions: +Python 3.7 ___ Python tracker

[issue28148] [Patch] Also stop using localtime() in timemodule

Ed Schouten added the comment: Does this patch look all right to you? -- Added file: http://bugs.python.org/file44667/patch-pytime-localtime-gmtime ___ Python tracker

[issue28148] [Patch] Also stop using localtime() in timemodule

Alexander Belopolsky added the comment: > Maybe we can just pick a prototype that's as Pythonesque as possible that > also fixes these shortcomings. Any thoughts? Yes, and just call it _PyTime_localtime without the ugly suffix. -- ___ Python

[issue28148] [Patch] Also stop using localtime() in timemodule

Ed Schouten added the comment: As a person who keeps a close eye on the Austin Group mailing lists (i.e., 'the POSIX working group'), my guess is that it's very unlikely that POSIX will ever add those *_s() extensions. Here's a discussion on Reddit that actually captures all of the arguments

[issue28148] [Patch] Also stop using localtime() in timemodule

Alexander Belopolsky added the comment: > we should likely introduce full wrappers that have a name starting with > _PyTime_, right? Yes, and I would like to give some thought to what the best API would be. The two choices are to emulate localtime_r on Windows or emulate localtime_s on

[issue28148] [Patch] Also stop using localtime() in timemodule

Ed Schouten added the comment: Hi Alexander, I'm absolutely no expert when it comes to the Python codebase, so I've got a question. If we're going to movein this to Include/pytime.h, we should likely introduce full wrappers that have a name starting with _PyTime_, right? This header seem to

[issue28148] [Patch] Also stop using localtime() in timemodule

Alexander Belopolsky added the comment: Yes, I think this is a good idea. I was hesitant to make this change while #22798 was open because I thought we may end up exposing changes to tzname caused by localtime and friends. I also believe we can classify this as a bug-fix because side-effects

[issue28148] [Patch] Also stop using localtime() in timemodule

Alexander Belopolsky added the comment: > What would be the right location for [the Windows wrappers]? I would say Include/pytime.h: /** Symbols and macros to supply platform-independent interfaces to time related

[issue28148] [Patch] Also stop using localtime() in timemodule

Changes by Ed Schouten : -- title: Also stop using localtime() in timemodule -> [Patch] Also stop using localtime() in timemodule ___ Python tracker