Movatterモバイル変換

• i18n
• unicode

C API: Universal Time Scale.

There are quite a few different conventions for binary datetime, depending on different platforms and protocols. Some of these have severe drawbacks. For example, people using Unix time (seconds since Jan 1, 1970) think that they are safe until near the year 2038. But cases can and do arise where arithmetic manipulations causes serious problems. Consider the computation of the average of two datetimes, for example: if one calculates them withaverageTime = (time1 + time2)/2, there will be overflow even with dates around the present. Moreover, even if these problems don't occur, there is the issue of conversion back and forth between different systems.

Binary datetimes differ in a number of ways: the datatype, the unit, and the epoch (origin). We'll refer to these as time scales. For example:

All of the epochs start at 00:00 am (the earliest possible time on the day in question), and are assumed to be UTC.

The ranges for different datatypes are given in the following table (all values in years). The range of years includes the entire range expressible with positive and negative values of the datatype. The range of years for double is the range that would be allowed without losing precision to the corresponding unit.

These functions implement a universal time scale which can be used as a 'pivot', and provide conversion functions to and from all other major time scales. This datetimes to be converted to the pivot time, safely manipulated, and converted back to any other datetime time scale.

So what to use for this pivot? Java time has plenty of range, but cannot represent .NETSystem.DateTime values without severe loss of precision. ICU4C time addresses this by using adouble that is otherwise equivalent to the Java time. However, there are disadvantages withdoubles. They provide for much more graceful degradation in arithmetic operations. But they only have 53 bits of accuracy, which means that they will lose precision when converting back and forth to ticks. What would really be nice would be along double (80 bits – 64 bit mantissa), but that is not supported on most systems.

The Unix extended time uses a structure with two components: time in seconds and a fractional field (microseconds). However, this is clumsy, slow, and prone to error (you always have to keep track of overflow and underflow in the fractional field).BigDecimal would allow for arbitrary precision and arbitrary range, but we do not want to use this as the normal type, because it is slow and does not have a fixed size.

Because of these issues, we ended up concluding that the .NET framework'sSystem.DateTime would be the best pivot. However, we use the full range allowed by the datatype, allowing for datetimes back to 29,000 BC and up to 29,000 AD. This time scale is very fine grained, does not lose precision, and covers a range that will meet almost all requirements. It will not handle the range that Java times do, but frankly, being able to handle dates before 29,000 BC or after 29,000 AD is of very limited interest.

Definition in fileutmscale.h.