What time fields should `struct stat` have?

[tgross35]

Prior discussion at #4942

@xbjfk said:

I would personally push for using timespec to:

* Closer match the libc source
* Be POSIX correct and match the correct C usage / docs / man pages.
* Have more compatibility with other architectures (hermit, AIX and hurd are already)
* Make struct definitions easier to read (especially with bi-endian architectures)
* We can remove a lot of test skips.

I personally think the best path forward would be to revert 55fa65b so that people can try the new experimental musl with less breaking changes (and fixing loongarch) and reintroduce the name change without a feature gate for all platforms in the 1.0 branch only for the reasons listed above (virtually every UNIX platform supported by libc uses timespec).

IIRC this was changed with time64 changes the because having conditional definitions for the padding was a bit unwieldy.

Will look into making a PR for this.

[tgross35]

I linked https://pubs.opengroup.org/onlinepubs/009695299/basedefs/sys/stat.h.html before, but https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_stat.h.html actually is the most recent. It defines:

struct timespec st_atim Last data access timestamp.
struct timespec st_mtim Last data modification timestamp.
struct timespec st_ctim Last file status change timestamp.

with the note:

For compatibility with earlier versions of this standard, the st_atime macro shall be defined with the value st_atim.tv_sec. Similarly, st_ctime and st_mtime shall be defined as macros with the values st_ctim.tv_sec and st_mtim.tv_sec, respectively.

So I am in favor of this change across the board for 1.0.