2

我正在对现有的多平台库进行更改。该库目前使用time_ttime(NULL)存储重要事件的“时间戳”,但秒分辨率已不够用。该库已经将 Boost 用于不同的事情,所以我正在考虑将所有time_t时间戳转换为 Boost.Date_Time 对象之一。

但是我对“Posix Time”和“Local Time”有点困惑。本地时间还包括时区的唯一区别是什么?似乎可以通过提供要使用的时区来将对象ptime转换为对象。local_date_time

我是否正确地认为我应该使用它ptime来存储时间戳,并让客户/呼叫者自己决定是否要转换为local_date_time是否需要它?

4

1 回答 1

4

简短的回答:

是的,boost ptime 将是最接近 time_t 的等价物;两者都是自纪元/开始记录时间类型的表示以来的秒数。并且 Boost ptime 可以在给定时区的情况下自由转换为 Boost local_date_time。

正常用途是存储通用时间戳并将其转换为本地有意义的时间,以便按需显示。所以,

东海岸服务器可能会在当地时间 2012 年 2 月 12 日 17:05 EST 记录一些事件,这将转换为自 2012 年 2 月 13 日 00:05 UTC 以来 Epoch 秒的 prime/time_t 内部表示并将其放入数据库。然后巴黎客户端可以转换为 local_date_time/struct tm 为 2012-02-13 01:05 CET,旧金山客户端可以转换为 2012-02-12 13:05 PST。

更长的答案:(可能与您在 time_t 上已经标准化的应用程序无关)

但是在某些情况下,如果地理组件具有某种意义,您可能会直接存储本地日期时间。您可能会想象世界各地有许多事件源,知道这些事件是本地的白天还是晚上可能会很有趣。您可能会恢复 2 种方式中的 1 种。直接存储本地日期时间/struct tm/或保留原始时区和本地时间的其他日期时间偏移/时区类型,例如 14:00 PST(白天)或 03:05 CET(夜间)。

或者将带有一些参考的事件存储到原始源,以便可以恢复时区。但是考虑到可能会删除源的维护,或者缺乏任何直接的连接,这通常比尝试对可能保存回时区的任何地理信息进行逆向工程更容易。

于 2012-02-13T04:28:51.343 回答