as a further explanation to:
” Comparsion of DateTime classes in popular programming Languages (1)”
This part is a copy and paste of lang/lib spec.
Range of Valid Dates
The range of valid dates is from January 2nd, 4713 BCE, to sometime in the year 11 million CE. The Julian Day returned by QDate::toJulianDay() is a number in the contiguous range from 1 to overflow, even across QDateTime’s “date holes”. It is suitable for use in applications that must convert a QDateTime to a date in another calendar system, e.g., Hebrew, Islamic or Chinese.36+41263
The Gregorian calendar was introduced in different places around the world on different dates. QDateTime uses QDate to store the date, so it uses the Gregorian calendar for all locales, beginning on the date 15 October 1582. For dates up to and including 4 October 1582, QDateTime uses the Julian calendar. This means there is a 10-day gap in the QDateTime calendar between the 4th and the 15th of October 1582. When you use QDateTime for dates in that epoch, the day after 4 October 1582 is 15 October 1582, and the dates in the gap are invalid.
Use of System Timezone
QDateTime uses the system’s time zone information to determine the offset of local time from UTC. If the system is not configured correctly or not up-to-date, QDateTime will give wrong results as well.
Daylight Savings Time (DST)
QDateTime takes into account the system’s time zone information when dealing with DST. On modern Unix systems, this means it applies the correct historical DST data whenever possible. On Windows and Windows CE, where the system doesn’t support historical DST data, historical accuracy is not maintained with respect to DST.
The range of valid dates taking DST into account is 1970-01-01 to the present, and rules are in place for handling DST correctly until 2037-12-31, but these could change. For dates falling outside that range, QDateTime makes a best guess using the rules for year 1970 or 2037, but we can’t guarantee accuracy. This means QDateTime doesn’t take into account changes in a locale’s time zone before 1970, even if the system’s time zone database supports that information.
NO leap second in Qt!
|Qt::LocalTime||0||Locale dependent time (Timezones and Daylight Savings Time).|
|Qt::UTC||1||Coordinated Universal Time, replaces Greenwich Mean Time.|
|Qt::OffsetFromUTC||2||An offset in seconds from Coordinated Universal Time.|
Use of Gregorian and Julian Calendars
QDate uses the Gregorian calendar in all locales, beginning on the date 15 October 1582. For dates up to and including 4 October 1582, the Julian calendar is used. This means there is a 10-day gap in the internal calendar between the 4th and the 15th of October 1582. When you use QDateTime for dates in that epoch, the day after 4 October 1582 is 15 October 1582, and the dates in the gap are invalid.
The Julian to Gregorian changeover date used here is the date when the Gregorian calendar was first introduced, by Pope Gregory XIII. That change was not universally accepted and some localities only executed it at a later date (if at all). QDateTime doesn’t take any of these historical facts into account. If an application must support a locale-specific dating system, it must do so on its own, remembering to convert the dates using the Julian day.
No Year 0
There is no year 0. Dates in that year are considered invalid. The year -1 is the year “1 before Christ” or “1 before current era.” The day before 0001-01-01 is December 31st, 1 BCE.
Some computer standards are defined in terms of Greenwich mean time (GMT), which is equivalent to universal time (UT). GMT is the “civil” name for the standard; UT is the “scientific” name for the same standard.
The UTC time-scale is a standard approach to bundle up all the additional fractions of a second from UT1 into whole seconds, known as leap-seconds. A leap-second may be added or removed depending on the Earth’s rotational changes. As such, UTC permits a day to have 86399 SI seconds or 86401 SI seconds where necessary in order to keep the day aligned with the Sun.
The modern UTC time-scale was introduced in 1972, introducing the concept of whole leap-seconds.
The distinction between UTC and UT is that UTC is based on an atomic clock and UT is based on astronomical observations, which for all practical purposes is an invisibly fine hair to split. Because the earth’s rotation is not uniform (it slows down and speeds up in complicated ways), UT does not always flow uniformly. Leap seconds are introduced as needed into UTC so as to keep UTC within 0.9 seconds of UT1, which is a version of UT with certain corrections applied. There are other time and date systems as well; for example, the time scale used by the satellite-based global positioning system (GPS) is synchronized to UTC but is not adjusted for leap seconds. An interesting source of further information is the U.S. Naval Observatory, particularly the Directorate of Time at:
and their definitions of “Systems of Time” at:
A new Date and Time API for JDK 8
System.currentTimeMillis() which returns the current time in milliseconds from January 1st 1970 (time_t)
Unix time (millisecond since unix epoch) time_t is just a int32_t (minus -1 means error to get timestamp),
also called timestamp, leading to Year-2038 problem
TAI epoch of 1958-01-01T00:00:00(TAI).
|java.util||Amended OpenJDK classes that integrate JSR-310 with the existing date and time APIs.|
|javax.time||Provides classes to manage the continuous time-scale including a wrapper for the system clock.|
|javax.time.calendar||Provides classes to manage the human time-scale including date, time, date-time and time-zone representations.|
|javax.time.calendar.format||Provides classes to print and parse dates and times.|
|javax.time.calendar.zone||Provides classes to implement time-zones and their rules.|
|javax.time.i18n||Provides classes representing dates and times in alternate calendar systems.|
Instant is immutable and thread-safe
The range of an instant requires the storage of a number larger than a
long. The standard storage scheme uses epoch-seconds measured from the standard Java epoch of
1970-01-01T00:00:00Z where instants after the epoch have positive values, and earlier instants have negative values. The standard storage stores the fraction of a second as nanosecond-of-second which will always be between 0 and 999,999,999.
|static Instant||now(Clock clock)Obtains the current instant from the specified clock.|
|static Instant||ofEpochMilli(long epochMilli)Obtains an instance of Instant using milliseconds from the epoch of 1970-01-01T00:00:00Z.|
|static Instant||ofEpochNano(java.math.BigInteger epochNano)Obtains an instance of Instant using nanoseconds from the epoch of 1970-01-01T00:00:00Z.|
|static Instant||ofEpochNano(long epochNano)Obtains an instance of Instant using nanoseconds from the epoch of 1970-01-01T00:00:00Z.|
|static Instant||ofEpochSecond(java.math.BigDecimal epochSecond)Obtains an instance of Instant using seconds from the epoch of 1970-01-01T00:00:00Z.|
|static Instant||ofEpochSecond(long epochSecond)Obtains an instance of Instant using seconds from the epoch of 1970-01-01T00:00:00Z.|
|static Instant||ofEpochSecond(long epochSecond, long nanoAdjustment)Obtains an instance of Instant using seconds from the epoch of 1970-01-01T00:00:00Z and nanosecond fraction of second.|
========================= Std C lib==========================
C struct tm* static allocated in <time.h>, shared by several API, easily be overwritten by each other!
Time Functionality in the Standard C Library
tzset (POSIX standard)
void tzset( void );
Reentrant Time Functions
To get around the problem of reentrancy in time functions, POSIX set forth a number of functions that don’t rely on static data. For example, asctime makes use of a per-thread string that gets changed every time it is called with a different struct tm. asctime_r does not suffer from this problem since a pointer to the string to be used is passed in. Here are all of the time functions that fall into this category:
char *asctime_r( const struct tm *timeptr,
char *ctime_r( const time_t *timer,
struct tm *gmtime_r( const time_t *timer,
struct tm *timeptr );
struct tm *localtime_r( const time_t *timer,
struct tm *timeptr );
Nevertheless, all these so-called reentrant functions still assume static data representations. The data in question is in the notion of time zone information.
However, tzset static information is an example of data that POSIX says may be defaulted in the case of the reentrant version of time functions it mandates. The library is allowed to make assumptions if the problem cannot be worked around, as it cannot in the case of missing library context. POSIX says, for example, that tzset need not be called in the reentrant time functions it mandates. This means that calls to these reentrant functions may use the library’s notion of time zone if the calling thread has no context from which to get information changed with respect to the system notions by the application.
Return the date corresponding to the proleptic Gregorian ordinal, where January 1 of year 1 has ordinal 1
Boost::second_clock is still based on time_t !
|Construct from a date and offset|
|Constructor for infinities, not-a-date-time, max_date_time, and min_date_time|
|Default constructor. Creates a ptime object initialized to not_a_date_time. NOTE: this constructor can be disabled by defining DATE_TIME_NO_DEFAULT_CONSTRUCTOR (see compiler_config.hpp)|
ptime p; // p => not_a_date_time
CC-BY-NC 4.0 licensed free for non-commercial usage
Author: Qingfeng XIA
copyright (C) 2011-2020
please keep the original link in your reference.