[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-ideas
Subject:    Re: [Python-ideas] Reduce platform dependence of date and time related functions
From:       random832 () fastmail ! us
Date:       2013-09-20 16:55:29
Message-ID: 1379696129.22168.24469709.2BA72C5C () webmail ! messagingengine ! com
[Download RAW message or body]

On Fri, Sep 20, 2013, at 11:59, Andrew Barnert wrote:
> 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.

We've basically got five "kinds" of locale we are talking about:

"C" locale - this is the easiest one to implement in a
platform-independent way, but probably the least useful (if you're not
intending locale-specific display, you should probably be using numeric
values)

Current platform locale, including all the subtleties like user
preferences you mentioned, when available. This is what we support now.

Specified platform locale (e.g. pt_BR, and we may still want to
translate from a single format rather than needing to specify 0x0416 or
"PTB" on Windows)

Platform-independent version of a specified locale, using e.g. CLDR.
This is the second-easiest to implement in a platform-independent way.

Platform-independent version of user's current locale. There are limits
to what can be achieved with this, for example Windows (and maybe Mac OS
- I know the pre-OSX versions did) lets you set certain things
individually. For example, I have my short date format set to
yyyy-MM-dd, but otherwise I'm in the en-US locale.

Anyway, this should be separate from the discussion of removing the
limitations of the platform code. Locale-specific data can be acquired
by calling the platform's strftime for a platform-independent strftime
just as it's done for strptime now - and we'd need it as a fallback
anyway. You can reduce the impact of platform's range limitations and
incompatible repertoire of format specifiers by doing them individually,
with a "safe" value for the year if needed, rather than throwing the
whole format string to the platform function.

For local time on windows, incidentally, we could extend the usable
range by calling SystemTimeToTzSpecificLocalTime, but that loses the
ability to use MSVCRT's version of the POSIX TZ variable.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
[prev in list] [next in list] [prev in thread] [next in thread]