yakovsh commented on PR #438: URL: https://github.com/apache/commons-compress/pull/438#issuecomment-1809221664
> Hello @yakovsh Thank you for your PR. Can you point to the TAR or PAX specifications for the legal value range? If there are legal values that we cannot represent in a Java Instant, then we need to not blow up but instead do... something else IMO. This range, whatever it is, should be documented in the code. TY! So the [POSIX standard](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_03) says that atime/ctime/mtime values are taken from stat which are **timespec** structures. Those are [defined](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html) as **time_t** for seconds and **long** for nanoseconds. Unfortunately, **time_t** is not clearly defined - [POSIX says](https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html) it could be a 32-bit signed integer, or a long. Further research shows that many Unix implementations use a signed 64-bit long (here is [an example from GNU C](https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html)). The choice of limits on **java.time.Instant* appears to be unrelated to any of this since it simply chooses years +1000000000/-1000000000 as limits. Not sure what the best approach here would be - looking through existing code, I am seeing several different ways to do this including 32-bit integer limits (TimeUtils.isUnixTime), storing this as a long value (ArArchiveEntry / CpioArchiveEntry) or using FileTime object (which uses Instant under the hood with the same problem). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
