[Python-ideas] Reduce platform dependence of date and time related functions

[Andrew Barnert]

On Sep 20, 2013, at 7:46, random832 at fastmail.us wrote:

> On Thu, Sep 19, 2013, at 18:00, Andrew Barnert wrote:
>> But that API implies that you could call, e.g., d.strftime(fmt, "pt_BR"),
>> which I assume isn't something anyone is planning on implementing.
> 
> Well, you could implement it by acquiring the GIL, setting the locale
> (putenv + setlocale), calling the platform strftime, and then resetting
> the locale afterward - all while locked, to prevent exposing the
> temporary strftime change to other code. (This also suggests a way to
> implement a tzinfo object in terms of native timezones)

OK, yes, you could do that, but are you actually proposing that the stdlib should do so? If not, it's a misleading API. If so, it's a much larger proposal than what we initially started with. And I think providing C-locale str[fp]time with very wide, platform-independent limits is a useful idea even without this much more radical idea.

> Long-term it would be nice to have python ship its own locale data,
> and/or to acquire platform-specific locale data via GetLocaleInfo[Ex] on
> windows and nl_langinfo on POSIX OSes where it is provided.

IIRC, OS X has a different set of (CoreFoundation-based?) APIs that take the system preferences into account as well as the locale setting, which might be worth using if you're designing the ultimate locale handling system; otherwise your apps won't act like native Cocoa apps.

For that matter, both Windows and OS X have more than one notion of the local date format (long vs. short names, etc.); do you want to expose that as well, or just stick to the POSIX-like subset of each platform's capabilities?

> (Note that
> the latter still would require stopping everything and setting the
> global locale to acquire the data, but since you've got to translate a
> locale name to a handle to use GetLocaleInfo or xlocale, it'd make sense
> to encapsulate this in a locale object which does all this upon being
> created. With platform strftime as a fallback. The issue with using
> platform strftime to populate things in advance is that %O is difficult
> and %E may be intractable.