Req #65717 [PATCH]: stat() should supply nano second granularity

Edit report at https://bugs.php.net/bug.php?id=65717&edit=1 ID: 65717 Patch added by: mchllmissouri@gmail.com Reported by: addw at phcomp dot co dot uk Summary: stat() should supply nano second granularity Status: Open Type: Feature/Change Request Package: Filesystem function related Operating System: Any PHP Version: Irrelevant Block user comment: N Private report: N New Comment: The following pull request has been associated: Patch Name: Disable bug reports completely On GitHub: https://github.com/php/web-bugs/pull/115 Patch: https://github.com/php/web-bugs/pull/115.patch Previous Comments: ------------------------------------------------------------------------ [2021-09-04 19:15:14] kevin at lyda dot ie Related To: Bug #78109 ------------------------------------------------------------------------ [2021-09-04 19:14:38] kevin at lyda dot ie This is also mentioned in bug 78109. ------------------------------------------------------------------------ [2013-09-21 00:45:25] aharvey@php.net I've got a patch that implements this, but I'm not totally happy with it right now — it works well enough for systems that provide this, but results in inconsistent behaviour for stream wrappers: whether the nanosecond fields are persisted depends on what's defined in sys/stat.h, since we use the system struct stat even though stream wrappers are theoretically decoupled from the OS. The better fix is probably to have our own php_stat struct that contains a consistent set of fields and then fill it in based on what the system provides, which we kind of do already at a higher level in stat() and friends. Since I got most of the way through the first version anyway, I've pushed it to GitHub: https://github.com/LawnGnome/php-src/compare/fr65717. Will continue tinkering with this to see if I can abstract away the system-specific stat struct as described above. ------------------------------------------------------------------------ [2013-09-20 08:30:27] addw at phcomp dot co dot uk My immediate problem is that I am trying to generate ETags that are compatible with those generated by Apache. Apache 'MTime' is of granularity microseconds. Unless I can determine the file modification time to an accuracy better than what PHP gives me I cannot do this. More to the point: if a facility is available, someone will find a use for it. It will not break backwards compatability since scripts that are not interested just don't look for the new members in the array. ------------------------------------------------------------------------ [2013-09-20 04:24:01] metamarkers at gmail dot com What would be a use case of this? Is there something inherently wrong with unix timestamps? Hardware has millisecond latency, I don't understand where having granularity down to the CPU cycle would be significant. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=65717 -- Edit this bug report at https://bugs.php.net/bug.php?id=65717&edit=1