我为 centos 5.3 编译了 python 2.6.4，发现这个问题是 os.path.getmtime() 或 os.stat().m_time 没有小数部分。根据文档，如果 os.stat_float_times() 返回 True，那么它应该返回浮点值。就我而言，我确实将其视为 float ，但没有小数部分(它为 0)。
In [3]: os.path.getmtime('/tmp')
Out[3]: 1268339116.0
In [4]: os.stat('/tmp')
Out[4]: posix.stat_result(st_mode=17407, st_ino=508897L, st_dev=29952L, st_nlink=7, st_uid=0, st_gid=0, st_size=4096L, st_atime=1268101696, st_mtime=1268339116, st_ctime=1268339116)
In [5]: os.stat_float_times()
True
In [6]: os.stat('/tmp').st_mtime
Out[6]: 1268339116.0
同样奇怪的是，stat() 输出看起来像一个 int。在 Windows 上，我确实看到了具有相同 python 版本的小数部分。我在 colinux 上运行 centos，这可能起到了一定的作用，还是某些 python 构建问题？我找不到任何针对通用 colinux 问题的匹配项。可能是 colinux 如何配置文件系统？在那种情况下我需要检查什么？
最佳答案
这是文件系统限制，而不是 Python 限制。 Centos 仍在 ext3 上，它提供整数 mtimes。如果您使用 ls 显示时间，您可以看到这一点。尝试
ls -ld --full-time /tmp
在我的 ext3 Centos 机器上，我得到
drwxrwxrwt 11 root root 69632 2010-03-11 13:16:30.000000000 -0800 /tmp
在我的 ext4 Ubuntu 机器上，我得到了
drwxrwxrwt 16 root root 20480 2010-03-11 21:20:02.088188962 +0000 /tmp
这在 ext4 Wikipedia article 中有描述:
Improved timestamps
As computers become faster in general and as Linux becomes used more for mission critical applications, the granularity of second-based timestamps becomes insufficient. To solve this, ext4 provides timestamps measured in nanoseconds. In addition, 2 bits of the expanded timestamp field are added to the most significant bits of the seconds field of the timestamps to defer the year 2038 problem for an additional 204 years.
关于python - os.path.getmtime() 不返回几分之一秒，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2428556/