> The fact that the bias may change between the two calls to os.date also seems to be irrelevant, because only one of the calls use the bias.
This assumes that the underlying timekeeping is in UTC. Which may or may not be true, and the user's time zone might be different from whatever time zone is used internally. For example, Windows uses the "system" time zone to store time in the hardware real-time clock [1], while the user might have any other time zone, so at least in certain cases both calls might involve different time biases, with each one being in the state of flux to make things funnier.
Your workaround ("compute things twice") will deal with that problem, though, it just feels like a... workaround :)
