You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Filetime.Nanoseconds() has a major drawback: the returned int64 is too
small to represent Filetime's zero value (January 1, 1601) in terms of
nanoseconds since Epoch (00:00:00 UTC, January 1, 1970); MinInt64 only
dates back to year 1677.
This has real-life implications, e.g., some Windows sub systems
(Perflib, to name one) create registry keys with the last write time
property set to zero. In this case, using Nanoseconds() reports an
underflow-affected value of 2185-07-22T00:34:33.709551+01:00.
This commit clearly marks the well-defined boundaries of Nanoseconds().
It introduces the new Unix() that returns a well-known pair of seconds
and nanoseconds (see other mentions in syscall.go) thus is capable to
cover the full range of Filetime values. Additionally, other conversions
related to Filetime are refactored to use full-range values where
possible, and to reflect boundaries in the docstring where not.
See also golang/go#74335
0 commit comments