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

[Rob Cliffe]

 From the sublime to the, er ... plebeian?  Just an idea for Python 4:
Is there any good reason to have separate time and datetime modules?
I sometimes find myself spinning my wheels converting between a format 
supported by one and a format supported by the other.
Rob Cliffe

On 16/09/2013 19:49, random832 at fastmail.us wrote:
> The practice of using OS functions for time handling has its worst
> effects on Windows, where many functions are unable to process times
> from before 1970-01-01 even though there is no reason for Python to have
> such a limitation. It also results in uneven support for strftime
> specifiers. Some of these functions also suffer from the Year 2038
> problem on OSes with a 32-bit time_t type.
>
> I propose supplying pure-python implementations (in accordance with PEP
> 399) for the entire datetime module, and additionally the asctime,
> strftime, strptime, and gmtime functions in the time module, and
> calendar.timegm. Unfortunately, functions dealing with local time stamps
> in the system's idea of local time are still dependent on the platform's
> C library functions (localtime, mktime, ctime)
>
> Or, if this is not practical, supplying alternate implementations of the
> relevant C functions, and calling these instead wherever these are used.
> If it is practical to do so, these functions should use python integers
> as the type for timestamps; if not, they should use 64-bit integers in
> preference to the platform time_t.
>
> Is it reasonable to expose the possibility of an epoch other than 1970
> (or of timestamps that handle leap seconds in a different manner than
> POSIX) at a python level? Even if such a platform ever comes to be
> supported, it could be done so with a layer that hides these
> differences.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2242 / Virus Database: 3222/6171 - Release Date: 09/16/13
>
>