Why can't python's datetime.max survive a round trip through timestamp / fromtimestamp?
Question: In most cases I can round-trip datetimes to and from a timestamp as follows:

    
    
    from datetime import datetime
    
    dt = datetime(2016, 1, 1, 12, 34, 56, 789)
    print(dt)
    print(datetime.fromtimestamp(dt.timestamp()))
    

> 2016-01-01 12:34:56.000789
>
> 2016-01-01 12:34:56.000789

But this doesn't work for datetime.max. Why is that?

    
    
    dt = datetime.max
    print(dt)
    print(datetime.fromtimestamp(dt.timestamp()))
    

> 9999-12-31 23:59:59.999999
>
> Traceback (most recent call last): File "python", line 9, in ValueError:
> year is out of range

More precisely, why hasn't the datetime library taken this case into account?


Answer: Simply because the maximum of a datetime object is not the same as the maximum
of a valid timestamp.

There's also a good reason to limit the range of timestamps: they are but a
simple python `float`, which, on "normal" machines are double precision
floating points. But: you lose more than a couple of seconds in precision:

    
    
    print(datetime.max.timestamp())
    253402297200.0
    print(datetime.max.second)
    59
    print(datetime.max.microsecond)
    999999
    

**spot the error.**

Timestamps based on floating point numbers are, _by definition_ less accurate
the more they are in the future. So not being able to represent arbitrary
valid `datetimes` in a timestamp is perfectly reasonable, just as restricting
one a couple thousand years in the future.

so:

> More precisely, why hasn't the datetime library taken this case into
> account?

Because timestamps so far in the future are unreliably and very likely do not
represent the time you've meant, so rejecting them is a wise thing.

Takeaway: a floating point number like `timestamp()` produces is not an
appropriate way of transporting times with fixed precision. If you at all can,
avoid it.

