如何在官方Windows Python 2.5上使用时间> 2038年

Fra*_*cis 4 python time time-t python-2.5 year2038

Windows上的官方Python 2.5是使用Visual Studio.Net 2003构建的,它使用32位time_t.因此,当年份> 2038年时,它只是例外.

虽然这在Python 2.6中已经修复(使用VS2008将time_t更改为64位),但我想使用2.5,因为已经为它编译了许多模块.

所以这是我的问题 - 是否有任何解决方案可以轻松让我的程序处理年份> 2038仍然使用官方Python 2.5?例如,一些预先制作的图书馆喜欢"time64"或"长期"等...

请不要告诉我升级到2.6+或忘记错误 - 我有理由需要让它工作,这就是我在这里发布问题的原因.

Ale*_*lli 6

datetime标准库中的模块应该可以正常工作.你怎么从一个模块需要time的是datetime不提供?

  • 是.datetime没有帮助 - 如果我需要得到time_t,如time.time(),则将Y2039传递给datetime将失败并显示消息"ValueError:timestamp超出平台time_t的范围".如果将系统时钟更改为2039年,则调用datetime.date.today()也会失败,因为"ValueError:timestamp超出了platform localtime()函数的范围".因此,datetime不会改变任何东西 - 它只是默认时间模块的包装器. (2认同)

Jas*_*n S 6

我不是说听起来很陈词滥调,但为什么不呢:

  • 忘掉Python 2.5的Y2038错误
  • 在2038年之前的某个时候升级到Python 2.6

编辑: 澄清:(我很认真 - 我不是故意嘲笑)

据推测,你可以在现在和2038年之间的某个无限期间将Python升级到2.6(或更高版本).也许在2012年.也许在2015年.也许在2037年.

如果您了解应用程序中的Python时间戳变量之间的差异(我不是Python用户),看起来这些是需要考虑的重要方面:

  • 什么数据被持续保存
  • 如何使用Python 2.6恢复已保留的Python 2.5时间戳变量(可能会"做正确的事情")
  • 老数据是否会以其持久的形式存储足够长的时间以产生歧义(例如,当考虑到1950年到2049年之间的年份"96"是明确的,但如果这些数据保持到2230年左右那么"96"可能是1996年,2096或2196)

如果答案是有利的,只需使用常规时间戳及其2038错误.您必须将其与重新设计/重构的数量进行比较,以使您的应用程序使用备用时间戳(例如,数据库时间戳字符串或其他)进行操作.

  • 为什么所有的讽刺反应?也许应用程序实际上需要代表2038年以后的日期_today_.我不知道,也许它是一个需要将预测与长期约会相关联的地质数据应用程序. (8认同)

Fra*_*cis 5

我发现的最好的解决方案是获取Python 2.5的源代码副本,并使用默认time_t为64位的编译器重新编译时间模块,例如VS2005或VS2008(也可以配置C运行时以防止并行)侧问题)。