I’m not sure that formula is correct. From our code the handle is:
“%08x%08x” % (int(time.time()*10000), _rand.randint(0, sys.maxsize))
So the observation that its the first 11 hex digits that of interest is probably correct.
And from the Python docs the time.time() is:
time. time () → float
Return the time in seconds since the epoch as a floating point number. The specific date of the epoch and the handling of leap seconds is platform dependent. On Windows and most Unix systems, the epoch is January 1, 1970, 00:00:00 (UTC) and leap seconds are not counted towards the time in seconds since the epoch.
The description of date.fromtimestamp() is:
classmethod date. fromtimestamp (timestamp )
Return the local date corresponding to the POSIX timestamp, such as is returned by time.time().
This may raise OverflowError, if the timestamp is out of the range of values supported by the platform C localtime() function, and OSError on localtime() failure. It’s common for this to be restricted to years from 1970 through 2038. Note that on non-POSIX systems that include leap seconds in their notion of a timestamp, leap seconds are ignored by fromtimestamp().
So I don’t think you need to perform any arithmetic to get the local time, just run the first 11 hex digits converted to float to date.fromtimestamp.