C/C++ Time Programming - References

[Steve Hathaway <sh...@e-z.net>]

Samuel,

Here are some of my accumulated platform compatibility notes
on 64-bit arithmetic and possible issues regarding a time-continuum
clock.

Factors in choosing a date-time continuum (64-bit integer arithmetic).

We should try to use a 64-bit integer for our time continuum.
The value in milliseconds (before and after) 1970-01-01T00:00Z
has usability beyond +- 292 million years.  This is becoming a
standard in the Java community.

Different C/C++ platforms have incompatible interpretations of 64-bit
integer values.  But they all appear to support 64-bit integer
arithmetic operations.


JAVA

Joda-Time and JDK implement a date-time clock implemented as
a Long() 64-bit data type.  This is a counter with zero based
on the ISO date of 1970-01-01T00:00:00.000Z counting in milliseconds.

[1]  http://joda.sourceforge.net  and  http://joda-time.sourceforge.net

C#

Noda-Time is an implementation of Joda-Time for Microsoft .NET
framework using Microsoft C# programming language.

C/C++

There currently is no Joda-Time implementation for C/C++.
When we implement a date-time class for Xalan-C, it may be wise
to use class and method names that are similar in purpose to
those implemented in the Joda-Time project.

Here is a proposal to implement an enhanced-time capability
to the C/C++ programming languages.  It is beyond the scope of our
project, but I think it is an interesting reference

[2]   http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2005/n1900.pdf

The basic UNIX time clock - and the underlying C libraries implement
a time_t value as long-int (32-bit) counter in seconds with zero based
on the ISO date of 1970-01-01T00:00:00.000Z.  This counter has a
rollover vulnerability every 68 years. A second value of microseconds
or nanoseconds is often made available in some time structures.

Newer implementations of UNIX time clock implement the time_t
counter as a long-long-int (64-bit) counter, still using seconds.
This is still an issue if you need sub-second time rendering
and still is missing good timezone support in the C/C++ libraries.

[3]   http://blog.joda.org/2011/08/joda-time-v20_2861.html

I did find a [pdf] file on creating a C/C++ library for calendaring, not 
based on
joda-time, but serving the same functionality.  I will try to find the 
reference.
I found it in a google search using "enhanced time" "C++".

Most C/C++ compiler platforms, even on 32-bit machines, handle
64-bit arithmetic.

Most 32-bit and some 64-bit platforms define these integer types.

    int = 32 bit
    long int = 32 bit
    long long int = 64 bit

Some 64-bit platforms define these integer types.
Gnu if __WORDSIZE == 64

    int = 32 bit
    long int = 64 bit

Microsoft declares thes platform independent types for use with
both 32-bit and 64-bit Windows operating systems. This is available
with C/C++ (VC6, VC7.1, VC8, VC9, VC10) compilers.

    __int32 = signed 32 bit integer
    __int64 = signed 64 bit integer

GNU C/C++ compilers and libraries define these.

<bits/types.h>

    __int32_t
    __uint32_t
    __int64_t
    __uint64_t

<stdint.h> and <sys/types.h>

    int32_t = signed 32 bit integer
    int64_t = signed 64 bit integer
    uint32_t = unsigned 32 bit integer
    uint64_t = unsigned 64 bit integer

The 'C' language printf("format",...) function has incompatible
format differences when representing 64-bit integer output.

GNU C printf("format")

    %d = signed integer
    %ld = signed long
    %lld = signed long long

Windows printf("format")

    %d = signed integer
    %I32d = signed long
    %I64d = signed long long

-------------------------------

Platforms I have tested 64-bit Arithmetic

   GNU (old library) on 2.2.17 Linux Kernel
     gcc version egcs-2.91.66 (egcs-1.1.2 release)
     libc version dated 1999
     Hardware = i486, pentium-75

   GNU (reasonably current) on 2.4.x and 2.6.x Linux Kernels

   Windows Visual Studio (2003, 2005, 2008, 2010)
     compilers VC7.1, VC8, VC9, VC10

-------------------------------

Getting usable platform-independent macros - XERCESC

<xercesc/util/Xerces_autoconf_config.hpp>

   For WINDOWS

     #define XERCES_S16BIT_INT  signed short
     #define XERCES_U16BIT_INT  unsigned short
     #define XERCES_S32BIT_INT  INT32
     #define XERCES_U32BIT_INT  UINT32

     While VC6 has 64-bit int, there is no support in the libraries
     (e.g., iostream), so Xerces is going tostick to 32-bit ints for VC6.
     VC7 and newer have support in the libraries for 64-bit ints.
     Note: The releases of XERCES-C 3.0 and newer do not support VC6.

     #if (_MSC_VER >= 1300)
     # define XERCES_S64BIT_INT  INT64
     # define XERCES_U64BIT_INT  UINT64
     #else
     # define XERCES_S64BIT_INT  INT32
     # define XERCES_U64BIT_INT  UINT32
     #endif

     XMLch is typedef to a 16-bit integer type (Used to store UTF-16 
native encoding)

     #ifdef _NATIVE_WCHAR_T_DEFINED
     # define XERCES_XMLCH_T     wchar_t
     #else
     # define XERCES_XMLCH_T     unsigned short
     #endif

     typedef XERCES_XMLCH_T      XMLCh;
     typedef XERCES_U16BIT_INT   XMLUInt16;
     typedef XERCES_U32BIT_INT   XMLUInt32;
     typedef XERCES_U64BIT_INT   XMLUint64;

   Borland C/C++

     Supports 64-bit integer arithmetic in the libraries.
     Has 16-bit wchar_t

   For UNIX

     If wchar_t exists and is 16 bit
       typedef XERCES_XMLCH_T  wchar_t
     Else
       typedef XERCES_XMLCH_T  unsigned short

-------------------------------

Getting usable platform-independent macros - XALANC

<xalanc/Include/PlatformDefinitions.hpp>

      Picks some XERCES configuration information to import from:
<xercesc/util/XercesDefs.hpp>  for C++
<xercesc/util/Xerces_autoconf_config.hpp"  for 'C'
<xercesc/util/XercesVersion.hpp"  for 'C'

      Selects platform-specific configurations from:
<xalanc/Include/VCPPDefinitions.hpp>  -- _MSC_VER
<xalanc/Include/GCCDefinitions.hpp>  -- __GNUCC__
<xalanc/Include/AIXDefinitions.hpp>  -- _AIX
<xalanc/Include/HPUXDefinitions.hpp>  -- __hpux
<xalanc/Include/SolarisDefinitions.hpp>  -- SOLARIS
<xalanc/Include/OS390Definitions.hpp>  -- OS390
<xalanc/Include/OS400Definitions.hpp>  -- OS400
<xalanc/Include/TRU64Definitions.hpp>   -- __DECCXX {for ULTRIX}
<xalanc/Include/IntelDefinitions.hpp>  -- __INTEL_COMPILER
<xalanc/Include/AIXDefinitions.hpp>  -- __IBMCPP__ and __TOS_LINUX__

-------------------------------

About Leap Seconds

There are several clock standards:

TAI is the international atomic clock time standard.  There are
no Leap Seconds on this clock.

UTC1 is the rotation of the earth time standard.  There are no
Leap Seconds on this clock.  This is one of the astronomical
time standards.

UTC is bound to the TAI with an accumulated difference of Leap Seconds.
UTC uses the TAI clock ticks and is adusted with Leap Seconds.

A Leap Second is performed on the UTC when its drift using TAI
clock ticks creates a difference of 0.9 seconds from the UTC1 clock.
The Leap Second is added or subtracted to UTC thus reducing its
error with the UTC1 earth rotation standard.

The UTC clock is used in computer time. The TAI clock is used for
GPS.

When Leap Second processing takes place, those time systems that
cannot handle an immediate adjustment are recommended to phase the
UTF adjustment over a period of 100 seconds.

For long-term stability of earth seasonal calendars, I believe that
the UTC time should remain closely linked with the UTC1 clock.
The ticks associated with the TAI standard are a useful technical
compromise for measurement accuracy.

There is some scientific talk about abandoning the Leap Second
adjustments to UTC time.  A vote will be taking place in the year
2015.

Sincerely,
Steven J. Hathaway
Xalan Documentation Project



---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org