Before this patch, tarantool.Datetime constructor used datetime.fromtimestamp function to build a new datetime [1], except for negative timestamps for Windows platform. This constructor branch is used on each Tarantool datetime encoding or while building a tarantool.Datetime object from timestamp. datetime.fromtimestamp have some drawbacks: it "may raise OverflowError, if the timestamp is out of the range of values supported by the platform C localtime() or gmtime() functions, and OSError on localtime() or gmtime() failure. It’s common for this to be restricted to years in 1970 through 2038.". It had never happened on supported Unix platforms, but seem to be an issue for Windows ones. We already workaround this issue for years smaller than 1970 on Windows. After this patch, this workaround will be used for all platforms and timestamp values, allowing to provide similar behavior for platforms both restricted to years in 1970 through 2038 with localtime() or gmtime() or not.
Before this patch, tarantool.Datetime constructor used datetime.fromtimestamp function to build a new datetime [1], except for negative timestamps for Windows platform. This constructor branch is used on each Tarantool datetime encoding or while building a tarantool.Datetime object from timestamp. datetime.fromtimestamp have some drawbacks: it "may raise OverflowError, if the timestamp is out of the range of values supported by the platform C localtime() or gmtime() functions, and OSError on localtime() or gmtime() failure. It’s common for this to be restricted to years in 1970 through 2038.". It had never happened on supported Unix platforms, but seem to be an issue for Windows ones. We already workaround this issue for years smaller than 1970 on Windows. After this patch, this workaround will be used for all platforms and timestamp values, allowing to provide similar behavior for platforms both restricted to years in 1970 through 2038 with localtime() or gmtime() or not.