[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review

[Guido van Rossum]

On Wed, Feb 15, 2012 at 11:38 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> *Apart* from the specific use case of making an exact copy of a
>> directory tree that can be verified by other tools that simply compare
>> the nanosecond times for equality, I don't see any reason for
>> complicating so many APIs to preserve the fake precision. As far as
>> simply comparing whether one file is newer than another for tools like
>> make/scons, I bet that it's in practice impossible to read a file and
>> create another in less than a microsecond. (I actually doubt that you
>> can do it faster than a millisecond, but for my argument I don't need
>> that.)
>
> But this leads to the issue with specialized APIs just for nanoseconds
> (as the one you just proposed): people will use them *just because they
> are there*.
>
> It's like the byte-oriented APIs to do file names: most applications
> won't need them, either because the file names convert into character
> strings just fine, or because the emulation that we (now) provide will
> fall back to some nearly-accurate representation. Still, just because we
> have the byte APIs, people use them, to then find out that they don't
> work on Windows, so they will write very complicated code to make their
> code 100% correct.
>
> The same will happen with specialized API for nanosecond time stamps:
> people will be told to use them because it might matter, and not knowing
> for sure that it won't matter to them, they will use them.
>
> Therefore, I feel that we must not introduced such specialized APIs.

You have a point, but applies just as much to the proposal in the PEP
-- floats and Decimal are often not quite compatible, but people will
pass type=Decimal to the clock and stat functions just because they
can. The problems with mixing floats and Decimal are probably just as
nasty as those with mixing byte and str. At least if people are mixing
nanoseconds (integers) and seconds (floats) they will quickly notice
results that are a billion times off.

> Not supporting ns timestamps is something I can readily agree to.

Me too.

> However, contributors won't agree to that, and will insist that these
> be added (and keep writing patches to do so) until it does get added.
> Some of them are core contributors, so there is no easy way to stop
> them :-)

Actually I think a rejected PEP would be an excellent way to stop this.

Maybe an alternative PEP could be written that supports the filesystem
copying use case only, using some specialized ns APIs? I really think
that all you need is st_{a,c,m}time_ns fields and os.utime_ns().

-- 
--Guido van Rossum (python.org/~guido)