Logo Search packages:      
Sourcecode: icu version File versions

Typedefs | Enumerations | Functions

utmscale.h File Reference

C API: Universal Time Scale. More...

#include "unicode/utypes.h"
Include dependency graph for utmscale.h:
This graph shows which files directly or indirectly include this file:

Go to the source code of this file.


typedef enum UDateTimeScale UDateTimeScale
typedef enum UTimeScaleValue UTimeScaleValue


enum  UDateTimeScale {
enum  UTimeScaleValue {


U_STABLE int64_t U_EXPORT2 utmscale_fromInt64 (int64_t otherTime, UDateTimeScale timeScale, UErrorCode *status)
U_STABLE int64_t U_EXPORT2 utmscale_getTimeScaleValue (UDateTimeScale timeScale, UTimeScaleValue value, UErrorCode *status)
U_STABLE int64_t U_EXPORT2 utmscale_toInt64 (int64_t universalTime, UDateTimeScale timeScale, UErrorCode *status)

Detailed Description

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 with averageTime = (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:

Table 1: Binary Time Scales
Source Datatype Unit


UDTS_JAVA_TIME int64_t milliseconds Jan 1, 1970
UDTS_UNIX_TIME int32_t or int64_t seconds Jan 1, 1970


double milliseconds Jan 1, 1970


ticks (100 nanoseconds) Jan 1, 1601

ticks (100 nanoseconds)

Jan 1, 0001
UDTS_MAC_OLD_TIME int32_t or int64_t seconds

Jan 1, 1904

UDTS_MAC_TIME double seconds

Jan 1, 2001

UDTS_EXCEL_TIME ? days Dec 31, 1899
UDTS_DB2_TIME ? days

Dec 31, 1899

UDTS_UNIX_MICROSECONDS_TIME int64_t microseconds Jan 1, 1970

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.

Units int64_t double


1 sec 5.84542x1011 285,420,920.94 136.10
1 millisecond 584,542,046.09 285,420.92 0.14

1 microsecond

584,542.05 285.42 0.00
100 nanoseconds (tick) 58,454.20 28.54 0.00
1 nanosecond 584.5420461 0.2854 0.00

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 .NET System.DateTime values without severe loss of precision. ICU4C time addresses this by using a double that is otherwise equivalent to the Java time. However, there are disadvantages with doubles. 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 a long 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's System.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 file utmscale.h.

Generated by  Doxygen 1.6.0   Back to index