I don't really understand the original issue.

I tested on a UTC+8 machine and both forms return the same result. datetime.fromtimestamp(0) also returns a naive datetime of local time zone.

from datetime import datetime

dt = datetime.strptime("2020-10-12 11:24:00.0000", "%Y-%m-%d %H:%M:%S.%f")
print((dt - datetime.fromtimestamp(0)).total_seconds())
print(dt.timestamp())
print(datetime.fromtimestamp(0))

Output:

1602473040.0
1602473040.0
1970-01-01 08:00:00

A naive calculation doesn't consider daylight saving time. When daylight saving time is in effect, as it is today in Seattle, you see this:

>>> dt = datetime.strptime("2020-10-12 11:24:00.0000", "%Y-%m-%d %H:%M:%S.%f")
>>> (dt - datetime.fromtimestamp(0)).total_seconds() - dt.timestamp()
3600.0

Ah. I see. Interesting. We don't have daylight saving time. 😆

Perhaps CLI should have stuck with UTC from the very beginning.

It's too late to change "expiresOn", but a new field like "expiresOnUTC" could solve the problem.

To add a little bit more context, datetime.strptime("2020-10-12 11:24:00.0000", "%Y-%m-%d %H:%M:%S.%f") returns a naive datetime, so dt - datetime.fromtimestamp(0) doesn't take daylight saving time into consideration.

Meanwhile, according to https://docs.python.org/3/library/datetime.html#datetime.datetime.timestamp,

Naive datetime instances are assumed to represent local time and this method relies on the platform C mktime() function to perform the conversion.

so datetime.timestamp() will take daylight saving time into consideration, thus being 3600 seconds smaller than the result of dt - datetime.fromtimestamp(0).