Wrong timestamp during migrating from v0.28 -> v1.1.0

[Garrett-R]

According to this page, migrating from 0.28 -> 1.1.0 should be fine, but my timestamp is showing up as 1979.

Here's a simple example.

First, do pip install itsdangerous==0.24, then execute this script:

from itsdangerous import URLSafeTimedSerializer

signing_serializer = URLSafeTimedSerializer('blah-blah')
cookie_val = signing_serializer.dumps('My Message')
timestamp = signing_serializer.loads(cookie_val, return_timestamp=True)[1]
print(f'Got {cookie_val=} with {timestamp=} (itsdangerous 0.24)')

For me, the output was:

Got cookie_val='Ik15IE1lc3NhZ2Ui.EsUWgA.a1holhKzlayr2idrEYcOUQSObXs' with timestamp=datetime.datetime(2020, 12, 23, 17, 57, 20) (itsdangerous 0.24)

Now do pip install itsdangerous==1.1.0, then copy the cookie val from the print above (will be different each time) and paste it into the below script:

from itsdangerous import URLSafeTimedSerializer

signing_serializer = URLSafeTimedSerializer('blah-blah')
# (this val was from previous script)
previous_cookie_val = 'Ik15IE1lc3NhZ2Ui.EsUWgA.a1holhKzlayr2idrEYcOUQSObXs'
previous_timestamp = signing_serializer.loads(previous_cookie_val, return_timestamp=True)[1]
print(f'Got {previous_cookie_val=} with {previous_timestamp=} (itsdangerous 1.1.0)')

For me, the output is:

Got previous_cookie_val='Ik15IE1lc3NhZ2Ui.EsUWgA.a1holhKzlayr2idrEYcOUQSObXs' with previous_timestamp=datetime.datetime(1979, 12, 24, 17, 57, 20) (itsdangerous 1.1.0)

(notice it's 1979)

---

OS: Ubuntu 18.04
Python: 3.9

[davidism]

This is due to #46, and the issue is a duplicate of #120 and #126, which have some good discussion.

#46 and a bunch of other issues pointed out that it wasn't possible to work with timestamps before 2011, which could happen on embeded systems or those without NTP. I agreed that it made more sense to use the full timestamp from 1970 instead of 2011, and changed that here: 9981a90, which is why you see 1970 + 9 instead of 2011 + 9.

#120 noticed that it affected validation when upgrading. #126 and #133 fixes the validation logic so it checks timestamps in both directions, so there's at least a clear validation error message.

Sorry for the confusion, I understand it's frustrating to run into this. At this point, I don't think we're going to add more fallback code. Some fallback implementations that a project can use are proposed in #120.

[Garrett-R]

Thanks for the detailed response!