search

oetiker / rrdtool-2.x

RRDtool 2.x - The Time Series Database
86 stars 8 forks source link

Support 64bit time regardles of os time_t #22

Open oetiker opened 10 years ago

oetiker commented 10 years ago

on systems where time_t is 32 bit, rrdtool should still use 64bit to avoid 2038 time bug the https://github.com/schwern/y2038 library comes to mind.

pabigot commented 10 years ago

I'd like to probe this issue. What are the resolution and range requirements on timestamps that drive it?

Standard POSIX time_t currently used in rrdtool-1.x represents to 1s resolution from 1970-01-01T00:00:00Z through 2038-01-19T03:14:07 using a signed 32-bit integer.

Is the goal of 64-bit to increase the range or the resolution?

If the goal is to increase the resolution, selecting a 64-bit time_t will not accomplish it. My recommendation is to support an option to use NTP Epoch 0 timestamps, which represent times to 2^-32 s (sub-quarter-nanosecond) resolution from 1900-01-01T00:00:00 until 2036-02-07T06:28:16Z as an unsigned 64-bit integer. I propose rrdtool-2.x consider supporting this as an option, while retaining time_t for the more common case where 1s is adequate.

If the goal is to increase the range I think the goal is mistaken. RRDTool uses timestamps to record real-world events. The first instance where such an event will require a new range will not occur for over twenty years. By that time, there will assuredly be a standard approach for representing such timestamps and converting older timestamps, and anticipating a solution is misdirected effort.

In short I don't see a value in adding a dependency on y2038.