ICU4C, ICU4J API Proposal Universal Time Scale
Eric Mader <[email protected]> Fri, 24 Sep 2004 17:08:02 -0700
| Newsgroups | gmane.comp.lib.icu.general |
|---|---|
| Message-ID | <[email protected]> |
Please respond to this proposal by October 1st. This is a proposal to add support for a "universal time scale" which can be used as a "pivot" for conversion to and from the major time scales in use today. You can see the original API design here: http://oss.software.ibm.com/cvs/icu/~checkout~/icuhtml/design/formatting/universal_time_scale.html Since the APIs contain extensive documentation, I've added them as enclosures. Regards, Eric Mader IBM GCoC - San José 5600 Cottle Road M/S 50-2/B11 San Jose, CA 95193
UniversalTimeScale.java
(text/java, 11.5 KB)
/*
*******************************************************************************
* Copyright (C) 2004, International Business Machines Corporation and *
* others. All Rights Reserved. *
*******************************************************************************
*
*/
package com.ibm.icu.util;
import java.math.BigDecimal;
/**
* 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
* <code>averageTime = (time1 + time2)/2</code>, 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.
*
* <p>
* 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 border="1" cellspacing="0" cellpadding="4">
* <caption>
* <h3>Table 1: Binary Time Scales</h3>
*
* </caption>
* <tr>
* <th align="left">Source</th>
* <th align="left">Datatype</th>
* <th align="left">Unit</th>
* <th align="left">Epoch</th>
* </tr>
*
* <tr>
* <td>JAVA_TIME</td>
* <td>long</td>
* <td>milliseconds</td>
* <td>Jan 1, 1970</td>
* </tr>
* <tr>
*
* <td>UNIX_TIME</td>
* <td>int or long</td>
* <td>seconds</td>
* <td>Jan 1, 1970</td>
* </tr>
* <tr>
* <td>ICU4C</td>
*
* <td>double</td>
* <td>milliseconds</td>
* <td>Jan 1, 1970</td>
* </tr>
* <tr>
* <td>WINDOWS_FILE_TIME</td>
* <td>long</td>
*
* <td>ticks (100 nanoseconds)</td>
* <td>Jan 1, 1601</td>
* </tr>
* <tr>
* <td>WINDOWS_DATE_TIME</td>
* <td>long</td>
* <td>ticks (100 nanoseconds)</td>
*
* <td>Jan 1, 0001</td>
* </tr>
* <tr>
* <td>MAC_OLD_TIME</td>
* <td>int</td>
* <td>seconds</td>
* <td>Jan 1, 1904</td>
*
* </tr>
* <tr>
* <td>MAC_TIME</td>
* <td>double</td>
* <td>seconds</td>
* <td>Jan 1, 2001</td>
* </tr>
*
* <tr>
* <td>EXCEL_TIME</td>
* <td>?</td>
* <td>days</td>
* <td>Dec 31, 1899</td>
* </tr>
* <tr>
*
* <td>DB2_TIME</td>
* <td>?</td>
* <td>days</td>
* <td>Dec 31, 1899</td>
* </tr>
* </table>
*
* <p>
* All of the epochs start at 00:00 am (the earliest possible time on the day in question),
* and are assumed to be UTC.
*
* <p>
* 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.
*
* <table border="1" cellspacing="0" cellpadding="4">
* <tr>
* <th align="left">Units</th>
* <th align="left">long</th>
* <th align="left">double</th>
* <th align="left">int</th>
* </tr>
*
* <tr>
* <td>1 sec</td>
* <td align="right">5.84542×10¹¹</td>
* <td align="right">285,420,920.94</td>
* <td align="right">136.10</td>
* </tr>
* <tr>
*
* <td>1 millisecond</td>
* <td align="right">584,542,046.09</td>
* <td align="right">285,420.92</td>
* <td align="right">0.14</td>
* </tr>
* <tr>
* <td>1 microsecond</td>
*
* <td align="right">584,542.05</td>
* <td align="right">285.42</td>
* <td align="right">0.00</td>
* </tr>
* <tr>
* <td>100 nanoseconds (tick)</td>
* <td align="right">58,454.20</td>
* <td align="right">28.54</td>
* <td align="right">0.00</td>
* </tr>
* <tr>
* <td>1 nanosecond</td>
* <td align="right">584.5420461</td>
* <td align="right">0.2854</td>
* <td align="right">0.00</td>
* </tr>
* </table>
*
* <p>
* 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.
*
*<p>
* So what to use for this pivot? Java time has plenty of range, but cannot represent
* Windows datetimes 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
* <code>long double</code> (80 bits -- 64 bit mantissa), but that is not supported on most systems.
*
*<p>
* 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). <code>BigDecimal</code> would allow for arbitrary precision and arbitrary range,
* but we would not want to use this as the normal type, because it is slow and does not
* have a fixed size.
*
*<p>
* Because of these issues, we ended up concluding that the Windows 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 would, but frankly, being able to handle dates
* before 29,000 BC or after 29,000 AD is of very limited interest. However, for those cases,
* we also allow conversion to an optional <code>BigDecimal</code> format that would have arbitrary
* precision and range.
*
*/
public final class UniversalTimeScale
{
/**
* Used in the JDK. Data is a <code>long</code>. Value
* is milliseconds since January 1, 1970.
*
* @draft ICU 3.2
*/
static final int JAVA_TIME = 0;
/**
* Used in Unix systems. Data is an <code>int> or a <code>long</code>. Value
* is seconds since January 1, 1970.
*
* @draft ICU 3.2
*/
static final int UNIX_TIME = 1;
/**
* Used in the ICU4C. Data is a <code>double</code>. Value
* is milliseconds since January 1, 1970.
*
* @draft ICU 3.2
*/
static final int ICU4C_TIME = 2;
/**
* Used in Windows for file times. Data is a <code>long</code>. Value
* is ticks (1 tick == 100 nanoseconds) since January 1, 1601.
*
* @draft ICU 3.2
*/
static final int WINDOWS_FILE_TIME = 3;
/**
* Used in Windows for date time (?). Data is a <code>long</code>. Value
* is ticks (1 tick == 100 nanoseconds) since January 1, 0001.
*
* @draft ICU 3.2
*/
static final int WINDOWS_DATE_TIME = 4;
/**
* Used in older Macintosh systems. Data is an <code>int</code>. Value
* is seconds since January 1, 1904.
*
* @draft ICU 3.2
*/
static final int MAC_OLD_TIME = 5;
/**
* Used in the JDK. Data is a <code>double</code>. Value
* is milliseconds since January 1, 2001.
*
* @draft ICU 3.2
*/
static final int MAC_TIME = 6;
/**
* Used in Excel. Data is a <code>?unknown?</code>. Value
* is days since December 31, 1899.
*
* @draft ICU 3.2
*/
static final int EXCEL_TIME = 7;
/**
* Used in DB2. Data is a <code>?unknown?</code>. Value
* is days since December 31, 1899.
*
* @draft ICU 3.2
*/
static final int DB2_TIME = 8;
/* Conversion to 'universal time scale' */
/**
* Convert a <code>double</code> datetime from the given time scale to the universal time scale.
*
* @param otherTime The <code>double</code> datetime
* @param timeScale The time scale to convert from
*
* @return The datetime converted to the universal time scale
*
* @draft ICU 3.2
*/
static long from(double otherTime, int timeScale);
/**
* Convert a <code>long</code> datetime from the given time scale to the universal time scale.
*
* @param otherTime The <code>long</code> datetime
* @param timeScale The time scale to convert from
*
* @return The datetime converted to the universal time scale
*
* @draft ICU 3.2
*/
static long from(long otherTime, int timeScale);
/**
* Convert a <code>double</code> datetime from the given time scale to the universal time scale.
* All calculations are done using <code>BigDecimal</code> to guarantee that the value
* does not go out of range.
*
* @param otherTime The <code>double</code> datetime
* @param timeScale The time scale to convert from
*
* @return The datetime converted to the universal time scale
*
* @draft ICU 3.2
*/
static BigDecimal bigDecimalFrom(double otherTime, int timeScale);
/**
* Convert a <code>long</code> datetime from the given time scale to the universal time scale.
* All calculations are done using <code>BigDecimal</code> to guarantee that the value
* does not go out of range.
*
* @param otherTime The <code>long</code> datetime
* @param timeScale The time scale to convert from
*
* @return The datetime converted to the universal time scale
*
* @draft ICU 3.2
*/
static BigDecimal bigDecimalFrom(long otherTime, int timeScale);
/* Conversion from 'universal time scale' */
/**
* Convert a datetime from the universal time scale to a <code>double</code> in the given time scale.
*
* @param universal The datetime in the universal time scale
* @param timeScale The time scale to convert to
*
* @return The datetime converted to the given time scale
*
* @draft ICU 3.2
*/
static double toDouble(long universalTime, int timeScale);
/**
* Convert a datetime from the universal time scale stored as a <code>BigDecimal</code> to a
* <code>double</code> in the given time scale.
*
* @param universal The datetime in the universal time scale
* @param timeScale The time scale to convert to
*
* @return The datetime converted to the given time scale
*
* @draft ICU 3.2
*/
static double toDouble(BigDecimal universalTime, int timeScale);
/**
* Convert a datetime from the universal time scale stored as a <code>BigDecimal</code> to a
* <code>long</code> in the given time scale.
*
* @param universal The datetime in the universal time scale
* @param timeScale The time scale to convert to
*
* @return The datetime converted to the given time scale
*
* @draft ICU 3.2
*/
static long toLong(long universalTime, int timeScale);
/**
* Convert a datetime from the universal time scale to a <code>long</code> in the given time scale.
*
* @param universal The datetime in the universal time scale
* @param timeScale The time scale to convert to
*
* @return The datetime converted to the given time scale
*
* @draft ICU 3.2
*/
static long toLong(BigDecimal universalTime, int timeScale);
}
utmscale.h
(text/plain, 10.3 KB)
/*
*******************************************************************************
* Copyright (C) 2004, International Business Machines Corporation and
* others. All Rights Reserved.
*******************************************************************************
*/
#ifndef UTMSCALE_H
#define UTMSCALE_H
#include "unicode/utypes.h"
/**
* \file
* \brief 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
* <code>averageTime = (time1 + time2)/2</code>, 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.
*
* <p>
* 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 border="1" cellspacing="0" cellpadding="4">
* <caption>
* <h3>Table 1: Binary Time Scales</h3>
*
* </caption>
* <tr>
* <th align="left">Source</th>
* <th align="left">Datatype</th>
* <th align="left">Unit</th>
* <th align="left">Epoch</th>
* </tr>
*
* <tr>
* <td>JAVA_TIME</td>
* <td>int64_t</td>
* <td>milliseconds</td>
* <td>Jan 1, 1970</td>
* </tr>
* <tr>
*
* <td>UNIX_TIME</td>
* <td>int32_t or int64_t</td>
* <td>seconds</td>
* <td>Jan 1, 1970</td>
* </tr>
* <tr>
* <td>ICU4C_TIME</td>
*
* <td>double</td>
* <td>milliseconds</td>
* <td>Jan 1, 1970</td>
* </tr>
* <tr>
* <td>WINDOWS_FILE_TIME</td>
* <td>int64_t</td>
*
* <td>ticks (100 nanoseconds)</td>
* <td>Jan 1, 1601</td>
* </tr>
* <tr>
* <td>WINDOWS_DATE_TIME</td>
* <td>int64_t</td>
* <td>ticks (100 nanoseconds)</td>
*
* <td>Jan 1, 0001</td>
* </tr>
* <tr>
* <td>MAC_OLD_TIME</td>
* <td>int32_t</td>
* <td>seconds</td>
* <td>Jan 1, 1904</td>
*
* </tr>
* <tr>
* <td>MAC_TIME</td>
* <td>double</td>
* <td>seconds</td>
* <td>Jan 1, 2001</td>
* </tr>
*
* <tr>
* <td>EXCEL_TIME</td>
* <td>?</td>
* <td>days</td>
* <td>Dec 31, 1899</td>
* </tr>
* <tr>
*
* <td>DB2_TIME</td>
* <td>?</td>
* <td>days</td>
* <td>Dec 31, 1899</td>
* </tr>
* </table>
*
* <p>
* All of the epochs start at 00:00 am (the earliest possible time on the day in question),
* and are assumed to be UTC.
*
* <p>
* 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.
*
* <table border="1" cellspacing="0" cellpadding="4">
* <tr>
* <th align="left">Units</th>
* <th align="left">int64_t</th>
* <th align="left">double</th>
* <th align="left">int32_t</th>
* </tr>
*
* <tr>
* <td>1 sec</td>
* <td align="right">5.84542×10¹¹</td>
* <td align="right">285,420,920.94</td>
* <td align="right">136.10</td>
* </tr>
* <tr>
*
* <td>1 millisecond</td>
* <td align="right">584,542,046.09</td>
* <td align="right">285,420.92</td>
* <td align="right">0.14</td>
* </tr>
* <tr>
* <td>1 microsecond</td>
*
* <td align="right">584,542.05</td>
* <td align="right">285.42</td>
* <td align="right">0.00</td>
* </tr>
* <tr>
* <td>100 nanoseconds (tick)</td>
* <td align="right">58,454.20</td>
* <td align="right">28.54</td>
* <td align="right">0.00</td>
* </tr>
* <tr>
* <td>1 nanosecond</td>
* <td align="right">584.5420461</td>
* <td align="right">0.2854</td>
* <td align="right">0.00</td>
* </tr>
* </table>
*
* <p>
* 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.
*
*<p>
* So what to use for this pivot? Java time has plenty of range, but cannot represent
* Windows datetimes 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.
*
*<p>
* 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.
*
*<p>
* Because of these issues, we ended up concluding that the Windows 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.
*
*/
/**
* UDateTimeScale values are used to specify the time scale used for
* conversion into or out if the universal time scale.
*
* @draft ICU 3.2
*/
typedef enum UDateTimeScale {
/**
* Used in the JDK. Data is a Java <code>long</code> (<code>int64_t</code>). Value
* is milliseconds since January 1, 1970.
*
* @draft ICU 3.2
*/
JAVA_TIME = 0,
/**
* Used on Unix systems. Data is <code>int32_t</code> or <code>int64_t</code>. Value
* is seconds since January 1, 1970.
*
* @draft ICU 3.2
*/
UNIX_TIME,
/**
* Used in IUC4C. Data is a <code>double</code>. Value
* is milliseconds since January 1, 1970.
*
* @draft ICU 3.2
*/
ICU4C_TIME,
/**
* Used in Windows for file times. Data is an <code>int64_t</code>. Value
* is ticks (1 tick == 100 nanoseconds) since January 1, 1601.
*
* @draft ICU 3.2
*/
WINDOWS_FILE_TIME,
/**
* Used in Windows for dates and times (?). Data is an <code>int64_t</code>. Value
* is ticks (1 tick == 100 nanoseconds) since January 1, 0001.
*
* @draft ICU 3.2
*/
WINDOWS_DATE_TIME,
/**
* Used in older Macintosh systems. Data is an <code>int32_t</code>. Value
* is seconds since January 1, 1904.
*
* @draft ICU 3.2
*/
MAC_OLD_TIME,
/**
* Used in newer Macintosh systems. Data is a <code>double</code>. Value
* is seconds since January 1, 2001.
*
* @draft ICU 3.2
*/
MAC_TIME,
/**
* Used in Excel. Data is an <code>?unknown?</code>. Value
* is days since December 31, 1899.
*
* @draft ICU 3.2
*/
EXCEL_TIME,
/**
* Used in DB2. Data is an <code>?unknown?</code>. Value
* is days since December 31, 1899.
*
* @draft ICU 3.2
*/
DB2_TIME
} UDateTimeScale;
/* Conversion to 'universal time scale' */
/**
* Convert a <code>double</code> datetime from the given time scale to the universal time scale.
*
* @param otherTime The <code>double</code> datetime
* @param timeScale The time scale to convert from
* @param status The status code. Set to <code>U_ILLEGAL_ARGUMENT_ERROR</code> if the conversion is out of range.
*
* @return The datetime converted to the universal time scale
*
* @draft ICU 3.2
*/
U_DRAFT int64_t U_EXPORT2
utmscale_fromDouble(double otherTime, UDateTimeScale timeScale, UErrorCode *status);
/**
* Convert a <code>int64_t</code> datetime from the given time scale to the universal time scale.
*
* @param otherTime The <code>int64_t</code> datetime
* @param timeScale The time scale to convert from
* @param status The status code. Set to <code>U_ILLEGAL_ARGUMENT_ERROR</code> if the conversion is out of range.
*
* @return The datetime converted to the universal time scale
*
* @draft ICU 3.2
*/
U_DRAFT int64_t U_EXPORT2
utmscale_fromInt64(int64_t otherTime, UDateTimeScale timeScale, UErrorCode *status);
/* Conversion from 'universal time scale' */
/**
* Convert a datetime from the universal time scale to a <code>double</code> in the given time scale.
*
* @param universal The datetime in the universal time scale
* @param timeScale The time scale to convert to
* @param status The status code. Set to <code>U_ILLEGAL_ARGUMENT_ERROR</code> if the conversion is out of range.
*
* @return The datetime converted to the given time scale
*
* @draft ICU 3.2
*/
U_DRAFT double U_EXPORT2
utmscale_toDouble(int64_t universalTime, UDateTimeScale timeScale, UErrorCode *status);
/**
* Convert a datetime from the universal time scale to a <code>int64_t</code> in the given time scale.
*
* @param universal The datetime in the universal time scale
* @param timeScale The time scale to convert to
* @param status The status code. Set to <code>U_ILLEGAL_ARGUMENT_ERROR</code> if the conversion is out of range.
*
* @return The datetime converted to the given time scale
*
* @draft ICU 3.2
*/
U_DRAFT int64_t U_EXPORT2
utmscale_toInt64(int64_t universalTime, UDateTimeScale timeScale, UErrorCode *status);
#endif