<div dir="ltr">Sure. However, it's not only btrfs, that's just one example.<div><div><br></div><div>Take macOS again: although the default filesystem (APFS) only stores a 64-bit value containing nanoseconds since Jan 1, 1970 on disk, that's just one filesystem, not a fundamental restriction. The kernel and userspace file APIs pass times through with the full 64-bit time_t range. (This can be easily demonstrated with a FUSE filesystem.)</div><div><div><br class="gmail-Apple-interchange-newline"></div></div></div><div>IMO, the set of platforms where a 64-bit value is likely to be always-sufficient is probably just Windows -- there, the file APIs themselves restrict the number of bits required (representing time as an unsigned 64-bit quantity containing 100-nanosecond intervals since January 1, 1601), rather than just a particular filesystem's on-disk-storage method.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 11, 2018 at 11:08 AM Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Aug 10, 2018, at 11:47 PM, James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>> wrote:<br>
> <br>
> Btrfs stores 64-bit sec, and 32-bit nsec on disk, and you can set and get it fine on linux.<br>
<br>
A 128 bit time_point seems like a good way to model those platforms that can mount Btrfs.  A 128 bit time_point does not seem like a good way to model those platforms which can only support 64 bit time stamps.<br>
<br>
The authors of a std::lib should write non-portable code so that I don’t have to.<br>
<br>
Howard<br>
<br>
</blockquote></div>