When a ballot is encrypted using this library, and a timestamp is not provided, the tracking hash is computed with utils.to_ticks(datetime.utcnow()). Both to_ticks and utcnow have some problems:
to_ticks only works on naive timezone-unaware datetimes (e.g. created with now or utcnow). Using it on deserialized ISO-8601 timestamps will failto_ticks is based on the date 0001-01-01T00:00:00 in naive timezone-unaware form, which:
- creates very large tick values and risks int overflow
- is the absolute minimum that datetime can represent, and attempts to normalize to a timezone cause errors
to_ticks returns the number of seconds * 10e7, which is one one hundred millionth of a second - in between microseconds and nanoseconds. This inflates the size of the tick number massively, and is a non-standard unit.datetime.utcnow produces the date/time in UTC, but doesn't capture the timezone. Most other datetime logic (including the time math currently in to_ticks) assumes this is a local time, and performs the wrong calculations.
To address this, we've decided to switch to using the unix epoch (seconds since January 1, 1970 UTC). It's unambiguous and very common.
When a ballot is encrypted using this library, and a
timestampis not provided, the tracking hash is computed withutils.to_ticks(datetime.utcnow()). Bothto_ticksandutcnowhave some problems:to_ticksonly works on naive timezone-unaware datetimes (e.g. created withnoworutcnow). Using it on deserialized ISO-8601 timestamps will failto_ticksis based on the date0001-01-01T00:00:00in naive timezone-unaware form, which:to_ticksreturns the number of seconds * 10e7, which is one one hundred millionth of a second - in between microseconds and nanoseconds. This inflates the size of the tick number massively, and is a non-standard unit.datetime.utcnowproduces the date/time in UTC, but doesn't capture the timezone. Most otherdatetimelogic (including the time math currently into_ticks) assumes this is a local time, and performs the wrong calculations.To address this, we've decided to switch to using the unix epoch (seconds since January 1, 1970 UTC). It's unambiguous and very common.