Edit report at https://bugs.php.net/bug.php?id=65717&edit=1
ID: 65717 User updated by: addw at phcomp dot co dot uk 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: 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2013-09-19 21:54:21] addw at phcomp dot co dot uk Description: ------------ Some systems (eg Linux on kernel > 2.5.48) the 3 timestamp fields may be available with resolution of nanosecond. If these are available stat() should return in the array 3 extra members : atimensec, ctimensec and mtimensec. The resolution available also depends on the underlying file system. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=65717&edit=1
