The WWT web client currently has a bug with the displayed FOV (noticed by @patudom). The FOV initially shows as 60:00:00, as it should. However, if one zooms in, and then zooms out fully, the FOV shows as 59:59:60. See below:
This is due to the fact that the angle, upon zooming back out, ultimately lands on the value 59.99999999999999. The implementation of formatHms takes floors to determine the second and minute portions of the output. However, while the remaining seconds portion will be strictly less than 60, if the difference is less than the precision (specified by extraPrecision), the number of seconds shows as 60. While the example here uses the displayed FOV, this could potentially affect any displayed value formatted using Util::formatHms.
This PR fixes the issue by adding a small bit of logic for this case which sets the seconds to zero, adds one to the minutes, and propagates that change up to the hourlike component if necessary. I went with startsWith over a double equals check since (at least in some quick local testing) the speed of startsWith is invariant under changes to extraPrecision, while == slows down as extraPrecision is increased. I don't know if there's a more elegant way of doing this than propagating back up the decomposed values after doing the floor functions - I'm not immediately able to think of one, at least.
The WWT web client currently has a bug with the displayed FOV (noticed by @patudom). The FOV initially shows as 60:00:00, as it should. However, if one zooms in, and then zooms out fully, the FOV shows as 59:59:60. See below:
This is due to the fact that the angle, upon zooming back out, ultimately lands on the value 59.99999999999999. The implementation of
formatHmstakes floors to determine the second and minute portions of the output. However, while the remaining seconds portion will be strictly less than 60, if the difference is less than the precision (specified byextraPrecision), the number of seconds shows as 60. While the example here uses the displayed FOV, this could potentially affect any displayed value formatted usingUtil::formatHms.This PR fixes the issue by adding a small bit of logic for this case which sets the seconds to zero, adds one to the minutes, and propagates that change up to the hourlike component if necessary. I went with
startsWithover a double equals check since (at least in some quick local testing) the speed ofstartsWithis invariant under changes toextraPrecision, while==slows down asextraPrecisionis increased. I don't know if there's a more elegant way of doing this than propagating back up the decomposed values after doing the floor functions - I'm not immediately able to think of one, at least.