Permalink
Reply
On Friday, 1 August 2025 at 10:12:12 UTC, kdevel wrote:
>On Thursday, 31 July 2025 at 23:57:49 UTC, 0xEAB wrote:
>On Thursday, 31 July 2025 at 21:34:03 UTC, kdevel wrote:
>- Remove "hnsecs" [2]. Every time I read this I am under the
impression that somebody is mocking the SI prefix system [3].
It’s Win32’s unit of time.
Do you have any reference to MS documentation which defines "hnsecs"?
The granularity of time seems to be 100 ns which seems to be named
a "tick" [1]. I mean nobody would invent the "unit" "tKiBytes"
(tetra kibi-byte) when everybody calls it "pagesize" (on X86).
Well, “tetra” isn’t even an SI prefix, whereas hectonanosecond combines two SI prefixes, which isn’t allowed if you want to comply to SI rules, which we’re not bound to. In my personal opinion, hns is very much understandable.
Also, “tick” and “pagesize” in my brain sound like concepts relative to a platform (like size_t), whereas “tetrakibibyte” is an absolute measure of information and “hectonanosecond” is an absolute measure of time. A tick is in fact so murky that the C++20 STL requires clock types to have an is_steady member that returns true only if ticks have the same length.
I don’t know if D supports any platform in which ticks aren’t steady or are different from 100 ns. DMD probably not, but with GDC and LDC, I wouldn’t say no without investigating.
The C++ STL simply defines nanoseconds, and if you use a nanoseconds value that’s not a multiple of 100, that information might go unused. With 64 bits, you can only have so many values, and that is actually a problem: The amount of nanoseconds between the years 1 and 2026 is: 1E9 × 60 × 60 × 24 × 365.2425 × 2025, which is a number that requires 66 bits to store. With 64 bits, you only get from year 1 to around year 584. If you store an hns value, you can model 58,455 years, which is more than enough. Even if you take away one bit for sign and half the range for years before year 1, you still have 14,613 for each direction.
