Re: [openssl-users] Re: Find the difference in (milli|micro)seconds between two ASN1_TIME values

2012-11-07 Thread Erwann Abalea

Le 07/11/2012 16:08, Jakob Bohm a écrit :

On 11/7/2012 3:39 PM, Charles Mills wrote:
 A struct tm is only granular down to whole seconds, right?

Yes, and it is not the easiest data type for data math either, even
when restricted to GMT/UT1/UTC.

Plus many OS/compiler supplied struct tm related functions work badly
outside the range 1970 to 2037 (U2K38 bug and signedness issues).

What would be really nice would be a function that converted the time
to/from a signed bignum (OpenSSL type BN) of nanoseconds since
1970-01-01 00:00:00.0 GMT/UT1/UTC, counting GMT/UT1/UTC virtual
seconds not IAT SI seconds (so an input timestamp of 2012-06-30
23:59:60 would be counted as 2012-06-30 23:59:59 or 2012-07-01 00:00:00
and the straigt subtraction between 2012-06-30 23:59:00 and 2012-07-01
00:00:00 would be 1 hour (3600 seconds), not 3601 seconds).


Such a function would be useless.
There's only 60/61s between these 2 dates, not 3600/3601 ;)

I guess you also mean counting in TAI/POSIX seconds, since these don't 
include leap seconds, right?

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl-users] Re: Find the difference in (milli|micro)seconds between two ASN1_TIME values

2012-11-07 Thread Jakob Bohm

On 11/7/2012 7:34 PM, Erwann Abalea wrote:

Le 07/11/2012 16:08, Jakob Bohm a écrit :

On 11/7/2012 3:39 PM, Charles Mills wrote:
 A struct tm is only granular down to whole seconds, right?

Yes, and it is not the easiest data type for data math either, even
when restricted to GMT/UT1/UTC.

Plus many OS/compiler supplied struct tm related functions work badly
outside the range 1970 to 2037 (U2K38 bug and signedness issues).

What would be really nice would be a function that converted the time
to/from a signed bignum (OpenSSL type BN) of nanoseconds since
1970-01-01 00:00:00.0 GMT/UT1/UTC, counting GMT/UT1/UTC virtual
seconds not IAT SI seconds (so an input timestamp of 2012-06-30
23:59:60 would be counted as 2012-06-30 23:59:59 or 2012-07-01 00:00:00
and the straigt subtraction between 2012-06-30 23:59:00 and 2012-07-01
00:00:00 would be 1 hour (3600 seconds), not 3601 seconds).


Such a function would be useless.
There's only 60/61s between these 2 dates, not 3600/3601 ;)


OOPS, typo in the example, I first planned to write 23:00:00 as the
start of the difference example.  Point is the difference is 60 or 3600
in the UT0/UT1/UT2/GMT/POSIX time scales, 61 or 3601 in the TAI/GPS time
scale, and either in the UTC time scale depending on implementation.


I guess you also mean counting in TAI/POSIX seconds, since these don't
include leap seconds, right?


I mean counting UT1/GMT/POSIX seconds, but with no dependency on 
(broken) POSIX or broken POSIX/ANSI C time_t implementations (a common

problem in ASN TIME parsers I have seen the source code for).

In other words, use the rules decreed by the Engineering Head
(Pontiflex Maximus) of Rome, as refined into computer friendly math by
Gauss and others:

 * 1 day=24 hours of 60 minutes of 60 seconds, each day starts
  approximately when the meridian faces away from the Sun.
 * 365 days per year but 366 days if the year is a leap year.
 * A year is a leap year if its number is divisible by 400 or by 4 but
  not 100.  This rule is subject to change, but notice is expected to
  be given at least a century ahead of time.
 * Month placement within each year assumes the year starts with March,
  not January.
 * Months start every 367/12 days with rounding rules optimized for
  roman numerals.  Gauss and others have found alternate formulas
  giving giving the same results by rounding 367/12 to fractions with
  different divisors, such as 30.6=153/5.
 * The last month of the year (February) is truncated to get the
  desired year length.
 * We should ignore the old form of the rules that said all years have
  365 days, but the 24th day of February sometimes lasts 48 hours with
  two sunrises.

TAI/SI/GMT seconds (I misspelled it IAT, sorry) count the physical
progression of time and thus increase more or less when crossing
positive/negative leap seconds.  It is not very useful for relating
to calendar time, as the relationship includes a date-dependent factor
(placement of leap seconds) which is announced only a few months before
each occurs, and then needs to be distributed in formats understood by
different software that might need it.  The formal difference is that
TAI seconds and GMT seconds differe by a fixed number of seconds while
SI seconds have no fixed starting point.

In contrast, UT0/UT1/GMT time has a direct mathematical relationship
with (Western) calendar dates, a relationship which has only changed
twice in the past 2008 years (See above).

The formal difference between UT0, UT1, GMT and UTC is exactly when
sub-second variations in the earths orbit and rotation are
incorporated:

UT0 tracks the exact orbit and requires astronomical instruments for
measurement, it is perfect for Sundials and as an intermediary in
calculating UT1, UT2 and GMT.

UT1, UT2 and GMT employ different averaging algorithms to interpolate
between observations and extrapolate past the latest measurements.

UTC starts from UT1, throws away fractional deviations from TAI and
incorporate accumulated full second deviations at somewhat convenient
times decided by human scientists in Paris, similar to how pre-Julian
Roman calendars positioned the leap months and how the Islamic
calendar still positions the leap day at the end of each month.

When someone say they count UTC seconds, it is unclear if they are
counting the underlying TAI seconds or the number of UT1 seconds
using the UTC scale only to control rounding of individual date/time
points.

Additionally some narrow minded people are currently increasing
confusion by proposing rule changes to make the UTC acronym and
name refer to a permanently wrong timescale (TAI plus whatever
number of seconds was correct in an arbitrary year yet to be
selected, making it just another unworldly TAI format).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote