0.9.13 (3aa2028) Compiled/transpiled files recomputed because of faked stat64

[Xavier-Do]

We noticed a strange behavior regarding a python Deprecation warning in docutils 0.17 when using faketime

Long story short, it looks like python almost always recomputes the pyc files starting from #507

The issue may not be only python specific, since the stat changes any hash based on the file write date would change too.

git checkout ffdb51b
make && sudo make install

/usr/local/bin/faketime "2050-01-01 00:00 UTC" python3 ../tests/test.py
stat ../tests/__pycache__/imported.cpython-312.pyc 

...
Access: 2026-02-19 14:35:28.211059503 +0100
Modify: 2026-02-19 14:35:28.211059503 +0100
Change: 2026-02-19 14:35:28.211059503 +0100
 Birth: 2026-02-19 14:35:28.211059503 +0100

/usr/local/bin/faketime "2050-01-01 00:00 UTC" python3 ../tests/test.py
stat ../tests/__pycache__/imported.cpython-312.pyc 

...
Access: 2026-02-19 14:35:30.668987212 +0100
Modify: 2026-02-19 14:35:30.668987212 +0100
Change: 2026-02-19 14:35:30.669987183 +0100
 Birth: 2026-02-19 14:35:30.668987212 +0100

Modify and Birth date changed

Tested with the parent commit, the file stats do not change

git checkout HEAD^

Previous HEAD position was ffdb51b Merge pull request #507 from bjornfor/add-stat64
HEAD is now at 3aa2028 Merge pull request #509 from lisanet/master

make > /dev/null 
sudo make install 
/usr/local/bin/faketime "2050-01-01 00:00 UTC" python3 ../tests/test.py
stat ../tests/__pycache__/imported.cpython-312.pyc 

...
Access: 2026-02-19 14:35:56.575246250 +0100
Modify: 2026-02-19 14:35:56.575246250 +0100
Change: 2026-02-19 14:35:56.575246250 +0100
 Birth: 2026-02-19 14:35:56.575246250 +0100

/usr/local/bin/faketime "2050-01-01 00:00 UTC" python3 ../tests/test.py
stat ../tests/__pycache__/imported.cpython-312.pyc 

...
Access: 2026-02-19 14:36:01.301115129 +0100
Modify: 2026-02-19 14:35:56.575246250 +0100
Change: 2026-02-19 14:35:56.575246250 +0100
 Birth: 2026-02-19 14:35:56.575246250 +0100

Modify and Birth date unchanged

Note that it only occurs if the two subsequent execution are not to close (more than one second)

cc @bjornfor

[Xavier-Do]

Just a personal opinion:

Functionally it looks like faking existing date is not (always?) correct: If I want to simulate how a program would behave in 1 year, the existing files would remain the same. If I have an assertion saying that the write date of this file is too old and should be update, I will miss it.

Ideally, I would say that new files or new write operation during the execution of the process should be faked. Maybe that the faked date should only apply on the date higher than the initial process start date?