A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2011-January/107282.html below:

[Python-Dev] Implementing strftime Was: Checking input range in time.asctime and time.ctime

[Python-Dev] Implementing strftime Was: Checking input range in time.asctime and time.ctime [Python-Dev] Implementing strftime Was: Checking input range in time.asctime and time.ctimeAlexander Belopolsky alexander.belopolsky at gmail.com
Thu Jan 6 17:55:35 CET 2011
On Thu, Jan 6, 2011 at 11:30 AM, Eric Smith <eric at trueblade.com> wrote:
..
> Is strftime really so complex that we shouldn't just write our own? I'd be
> willing to do it. Over the years the platform strftime has caused any number
> of problems. The last time I looked at it we already have to do some work
> pre-parsing the format string and passing it off to platform strftime, so
> it's not like it's not already a maintenance hassle.
>

This is the subject of issue 3173:

http://bugs.python.org/issue3173

As far as I can tell, the main problem with implementing strftime is
that it has to be locale aware and locale API is as inconsistent/buggy
across platforms as strftime itself.


> I understand strptime is probably more complex and there's some value to
> having strptime/strftime coming from the same library. But I'd be willing to
> look at it, too.

strptime is already implemented (in pure python) by stdlib, but it
piggybacks on strftime for locale information.  See Lib/_strptime.py.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4