## Additions for a standard epoch HJW would like in ISO8601.

Expand Messages
• Some current time epochs are: 1. Unix 1970-01-01 it is a 32 bit signed integer. Will overflow 2038-01-19 03:14:07 2. Microsoft NT 1601-01-01 3. Visual C++
Message 1 of 4 , May 9, 2003
Some current time epochs are:
1. Unix 1970-01-01 it is a 32 bit signed integer.  Will overflow 2038-01-19 03:14:07
2. Microsoft NT 1601-01-01
3. Visual C++ 1899-12-30 8 byte (64 bit) floating point
4. Excel dates 1900-01-01
5. MD-DOS 1980-01-01
6. Windows 3.11 1980-01-01
7. Microsoft.NET 0001-01-01
8. IBM Mainframes 1900-01-01 8 byte (64 bit) integer
9. Lillian date 1582-10-14 8 byte (64 bit) floating point register. Gregorian Calendar started.

ISO-8601 5.2.1.4 Expanded dates. "-YYYY-MM-DD" and  "+YYYY-MM-DD"  would require an epoch to handle  "-9999-01-01".  For calculating interval days fast the Gregorian date must be converted to days.  A 32-bit integer binary register can hold values from -214,783,648 to +214,748.347 or a little more than 9 decimals digits(72 bits in decimal).  So this is no problem (±3,652,500 = ±10,000 years * 365.25 days per year).

However, ISO8601 time-intervals are a problem for 32-bit binary computers.  When time is added to dates and than converted to seconds, the number is too large for a 32-bit register computer.  That is the reason for these different epochs.   However, most 32-bit computers support a 64-bit floating point register and therefore sometimes that is used.  The mantissa in floating point registers uses bits, therefore the register can only support milli-seconds (.sss) as fractions of seconds.

The ISO-8601 specifications that looks like a momentous problem to me for a 32-bit computer that has no decimal register are:
5.5.4.3 Presentation of time-interval by its start and its duration
"YYYY-MM-DDThh:mm:ss/PnYnMnDTnHnMnS"
5.5.4.4 Presentation of time-intervals by it duration and its end
"PnYnMnDTnHnMnS/YYYY-MM-DDThh:mm:ss"
"PYYYY-MM-DDTnHnMnS/YYYY-MM-DDThh:mm:ss"
5.5.6.3 Recurring time-intervals
"Rn/YYYY-MM-DDThh:mm:ss/YYYY_mm_DDThh:mm:ss"

A few of IBM's computers have decimal arithmetic registers.  The US government often requires computers to support 31 decimals digits.  They specify values of "31.0" to "31.15" digits, a standard for COBOL. For speed a computer needs a decimal register (a register that can do decimal arithmetic rather than binary arithmetic) for these size fields.    Even the 64-bit binary computers can only handle a number of a little more than 19 decimal digits.

The fastest register in a computer is the unsigned integer registers (has only has positive numbers rather than the integer register that can have both negative and positive numbers).  The addresses in computers are usually unsigned integers.

A 64-bit binary integer register can easily store as seconds the range of dates as seconds.  Actual it is able to store hundredths of micro-seconds (sss,sss,sss,sss.sssssssss) (±10,000 years * 365.25 days * 86400 second per day for ±3,652,500.99999999 range)  or my preferred notation "f8".
"-9999-01-01T00:00:00" to   "+9999-12-31T23:59:59"

For speed purposes, it should be investigated if unsigned registers have any significant benefits.  That would require:
"-9999-01-01T00:00:00" have the value "1"  I will explain latter.

If a integer register is used than:
"0000-01-01T00:00:00" should be zero

Throughout history, men have repeatedly made the mistake of not providing for the value zero.
Fore example, calculating the number of floor between the floor two (+2)and the first basement (-1);
In the US (3 = +2 - (-1)  error actually 2) while in Europe it is correct because the ground floor is floor "0" so there are 3 floors or in a two-story house the second story is floor +1

Roman numerals do not have the value zero, they are ordinal numbers, and have +1 and -1 but no zero. That is the reason the calendar has "0001-01-01" AD and "0001-01-01" BC but no year zero.  That is the reason for "12" AM rather than "00" AM or PM.  Believe it or not, but ISO-8601 standards committee had people arguing that the time for start of the day should be "00:00:01"  rather than "00:00:00".  I would not be surprised if this was the reason for ISO-8601 5.3.2 Midnight which requires these to be equal
"1999-12-31T24:00:00" = "2000-01-01T00:00:00"

The concept of zero and infinity came slow to mathematicians.  It is not coming any easier to ISO-8601 standards.  Anyone who has worked with effective and discontinued dates knows the need for a way to represent unknown past dates and an unknown future dates.  They usual method is to use "0000-00-00" and "9999-99-99" respectively, which are invalid for ISO-8601.  Even an unknown birth date it would be nice to be able to use "0000-00-00" to show the date is not known.  ISO-8601 does not make provisions for unknown dates, just like the Romans made no provisions for zero.

These two dates can be represented in an integer register:
"0000-00-00" with a low value of 32 bits of ones "-2,147,483,648"
"9999-99-99" with the high value 31 bits low order bits of ones value of "+2,14,483,747"

These two dates can be represented if the unsigned register is used.
"0000-00-00" with be 32 bits of zeros or the value zero.
"9999-99-99" would be 32 bits of ones or the decimal value "18,446,744,073,709,551,615".
The epoch should be:
"-9999-01-01T00:00:00+16"  for maximum speed in a binary computer to get UT (GMT) time.

Rather than using seconds; if days and fraction of days were use (DDDDDDD,dddddddddddd) (7,305,000 days = 20,000 years * 365.25 days per year) than the accuracy could be increased to approximately hundreds of nano-seconds (.sssssssssss = .dddddddddddd fraction of a day).  The one problem is that seconds cannot be converted to fraction of days in the binary numbering system.  If days had 32 hours, hours had 64 minutes and minutes had 64 seconds than it would convert perfectly because these are powers of two.

To determine if unsigned registers would give any significant speed over signed integer registers would take me over 30 days.  I do not currently have the time.  Also, I am not sure what CPUs have unsigned registers.  In addition, will PDAs, GPSs and telephones ever have 64 bit registers and will they be signed or unsigned?  Maybe what is required, is a 32 bit unsigned integer standard with fraction of days (D,DDD,DDD.ddd) which will gives accuracy to the minute for epoch "0000-01-01"  to "9999-12-31" If more accuracy is require than another epoch must be used and a shorter range of dates supported.  I am not well informed in this area.

• HJW, Hi. It would help if this mail would start with an overview statement, so we know what problem it is you are trying to solve. Although the statements are
Message 2 of 4 , May 9, 2003
HJW,

Hi. It would help if this mail would start with an overview statement, so we
know what problem it is you are trying to solve. Although the statements are
suggestive of what the problem(s) might be, taken together it is hard to see a
logical connection among all of them. If there are several problems you would
like to propose solutions for, please state up front what they are.

My thoughts are:
1) yes, there are lots of time epochs.

2) Although decimal arithmetic is not frequently implemented in hardware, it
is very frequently available in software from most programming languages or
environments. I understand this is not as fast as hardware implementation, but
as it is fast enough for most financial and other applications that rely on
it, I suspect it is fast enough for most date arithmetic applications. I would
be happy to learn otherwise. Where is speed for date arithmetic causing a
problem? Or alternatively, where is the requirement for 64-bit arithmetic
causing a problem?

3) Interesting requirement, that there be a date-time value representing
"unknown". Instead of relying on the intracaciesof signed and unsigned storage
formats,
perhaps there should be a proposal for "unknown" that fits the model and
syntax of the standard.
Something like "+---" where "+YYYY-MM-DD" has all the numeric values removed.

The implementation in 64-bit etc. shouldn't matter to the standard.

tex

hjwoudenberg@... wrote:
>
> Some current time epochs are:
> 1. Unix 1970-01-01 it is a 32 bit signed integer. Will overflow 2038-01-19
> 03:14:07
> 2. Microsoft NT 1601-01-01
> 3. Visual C++ 1899-12-30 8 byte (64 bit) floating point
> 4. Excel dates 1900-01-01
> 5. MD-DOS 1980-01-01
> 6. Windows 3.11 1980-01-01
> 7. Microsoft.NET 0001-01-01
> 8. IBM Mainframes 1900-01-01 8 byte (64 bit) integer
> 9. Lillian date 1582-10-14 8 byte (64 bit) floating point register.
> Gregorian Calendar started.
>
> ISO-8601 5.2.1.4 Expanded dates. "-YYYY-MM-DD" and "+YYYY-MM-DD" would
> require an epoch to handle "-9999-01-01". For calculating interval days
> fast the Gregorian date must be converted to days. A 32-bit integer binary
> register can hold values from -214,783,648 to +214,748.347 or a little more
> than 9 decimals digits(72 bits in decimal). So this is no problem
> (±3,652,500 = ±10,000 years * 365.25 days per year).
>
> However, ISO8601 time-intervals are a problem for 32-bit binary computers.
> When time is added to dates and than converted to seconds, the number is too
> large for a 32-bit register computer. That is the reason for these
> different epochs. However, most 32-bit computers support a 64-bit floating
> point register and therefore sometimes that is used. The mantissa in
> floating point registers uses bits, therefore the register can only support
> milli-seconds (.sss) as fractions of seconds.
>
> The ISO-8601 specifications that looks like a momentous problem to me for a
> 32-bit computer that has no decimal register are:
> 5.5.4.3 Presentation of time-interval by its start and its duration
> "YYYY-MM-DDThh:mm:ss/PnYnMnDTnHnMnS"
> 5.5.4.4 Presentation of time-intervals by it duration and its end
> "PnYnMnDTnHnMnS/YYYY-MM-DDThh:mm:ss"
> "PYYYY-MM-DDTnHnMnS/YYYY-MM-DDThh:mm:ss"
> 5.5.6.3 Recurring time-intervals
> "Rn/YYYY-MM-DDThh:mm:ss/YYYY_mm_DDThh:mm:ss"
>
> A few of IBM's computers have decimal arithmetic registers. The US
> government often requires computers to support 31 decimals digits. They
> specify values of "31.0" to "31.15" digits, a standard for COBOL. For speed
> a computer needs a decimal register (a register that can do decimal
> arithmetic rather than binary arithmetic) for these size fields. Even the
> 64-bit binary computers can only handle a number of a little more than 19
> decimal digits.
>
> The fastest register in a computer is the unsigned integer registers (has
> only has positive numbers rather than the integer register that can have
> both negative and positive numbers). The addresses in computers are usually
> unsigned integers.
>
> A 64-bit binary integer register can easily store as seconds the range of
> dates as seconds. Actual it is able to store hundredths of micro-seconds
> (sss,sss,sss,sss.sssssssss) (±10,000 years * 365.25 days * 86400 second per
> day for ±3,652,500.99999999 range) or my preferred notation "f8".
> "-9999-01-01T00:00:00" to "+9999-12-31T23:59:59"
>
> For speed purposes, it should be investigated if unsigned registers have any
> significant benefits. That would require:
> "-9999-01-01T00:00:00" have the value "1" I will explain latter.
>
> If a integer register is used than:
> "0000-01-01T00:00:00" should be zero
>
> Throughout history, men have repeatedly made the mistake of not providing
> for the value zero.
> Fore example, calculating the number of floor between the floor two (+2)and
> the first basement (-1);
> In the US (3 = +2 - (-1) error actually 2) while in Europe it is correct
> because the ground floor is floor "0" so there are 3 floors or in a
> two-story house the second story is floor +1
>
> Roman numerals do not have the value zero, they are ordinal numbers, and
> have +1 and -1 but no zero. That is the reason the calendar has "0001-01-01"
> AD and "0001-01-01" BC but no year zero. That is the reason for "12" AM
> rather than "00" AM or PM. Believe it or not, but ISO-8601 standards
> committee had people arguing that the time for start of the day should be
> "00:00:01" rather than "00:00:00". I would not be surprised if this was
> the reason for ISO-8601 5.3.2 Midnight which requires these to be equal
> "1999-12-31T24:00:00" = "2000-01-01T00:00:00"
>
> The concept of zero and infinity came slow to mathematicians. It is not
> coming any easier to ISO-8601 standards. Anyone who has worked with
> effective and discontinued dates knows the need for a way to represent
> unknown past dates and an unknown future dates. They usual method is to use
> "0000-00-00" and "9999-99-99" respectively, which are invalid for ISO-8601.
> Even an unknown birth date it would be nice to be able to use "0000-00-00"
> to show the date is not known. ISO-8601 does not make provisions for
> unknown dates, just like the Romans made no provisions for zero.
>
> These two dates can be represented in an integer register:
> "0000-00-00" with a low value of 32 bits of ones "-2,147,483,648"
> "9999-99-99" with the high value 31 bits low order bits of ones value of
> "+2,14,483,747"
>
> These two dates can be represented if the unsigned register is used.
> "0000-00-00" with be 32 bits of zeros or the value zero.
> "9999-99-99" would be 32 bits of ones or the decimal value
> "18,446,744,073,709,551,615".
> The epoch should be:
> "-9999-01-01T00:00:00+16" for maximum speed in a binary computer to get UT
> (GMT) time.
>
> Rather than using seconds; if days and fraction of days were use
> (DDDDDDD,dddddddddddd) (7,305,000 days = 20,000 years * 365.25 days per
> year) than the accuracy could be increased to approximately hundreds of
> nano-seconds (.sssssssssss = .dddddddddddd fraction of a day). The one
> problem is that seconds cannot be converted to fraction of days in the
> binary numbering system. If days had 32 hours, hours had 64 minutes and
> minutes had 64 seconds than it would convert perfectly because these are
> powers of two.
>
> To determine if unsigned registers would give any significant speed over
> signed integer registers would take me over 30 days. I do not currently
> have the time. Also, I am not sure what CPUs have unsigned registers. In
> addition, will PDAs, GPSs and telephones ever have 64 bit registers and will
> they be signed or unsigned? Maybe what is required, is a 32 bit unsigned
> integer standard with fraction of days (D,DDD,DDD.ddd) which will gives
> accuracy to the minute for epoch "0000-01-01" to "9999-12-31" If more
> accuracy is require than another epoch must be used and a shorter range of
> dates supported. I am not well informed in this area.
>
>
>
>

--
-------------------------------------------------------------
Tex Texin cell: +1 781 789 1898 mailto:Tex@...
Xen Master http://www.i18nGuy.com

XenCraft http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
• As the ISO 8601 standard is designed for data interchange between computers using text rather than bytes of numbers, none of your arguments matter. How you
Message 3 of 4 , May 11, 2003
As the ISO 8601 standard is designed for data interchange between
computers using text rather than bytes of numbers, none of your
arguments matter. How you handle the data within your application
doesn't matter to anything else. And, of course, there's also the
ubiquitous "by mutual agreement" clause to cover cases where you do
interchange in other manners, but I would always insist upon text.
• Hello, although this is off-topic in this list, I would like to answer on any mistakes in the mail of hjwoudenberg. Fortunately the subject is related to the
Message 4 of 4 , May 15, 2003
Hello,

although this is off-topic in this list, I would like to answer on any
mistakes in the mail of hjwoudenberg. Fortunately the subject is
related to the subject of this list.

on 2003-05-10T00:23+02:00 hjwoudenberg wrote:

> Some current time epochs are:
> 1. Unix 1970-01-01 it is a 32 bit signed integer. Will overflow 2038-01-19
> 03:14:07

The overflow timestamp is 2106-02-07T06:28:16.

But any applications, that at after 2038-01-19T03:14:07 the value
consider as signed 32 bit value, will display a wrong value.

Note, that this date/time format is mainly intended for file dates.

> 2. Microsoft NT 1601-01-01

This is a used in Microsoft Win9x also, called FILETIME. The value is
stored as 64 bit integer, the resolution is 100 ns, therefore this
format overflow in the year 60056.

This format is mainly intended for file dates. There are furthermore
date/time formats in Windows and Windows NT.

> 3. Visual C++ 1899-12-30 8 byte (64 bit) floating point

This isn't the Visual C++ format, rather the OLE2 date format. The
'standard' Visual C++ date format is the unix date format. The OLE2
date format is e.g. used in MFC (a Visual C++ class library),
VisualBASIC and Borland Delphi since Version 2.

> 4. Excel dates 1900-01-01

The Excel helpfile is inaccurate, Excel for Windows use the OLE2 date
format. Please note, that Excel for Windows (at least older versions)
have a bug, the developer do mean, that 1900 is a leap year:

Value 1 -> 1900-01-01
Value 59 -> 1900-02-28
Value 60 -> 1900-02-29
Value 61 -> 1900-03-01

Therefore this bizarre start value. I'm not sure, whether this bug is
also exists in the MFC date class or VisualBASIC, Delphi work correctly
from 0001-01-01T00:00:00 to 9999-12-31T23:59:59,999

Excel for Macintosh use a other date format, the value 0 correspond to
1904-01-01T00:00:00.

> 5. MD-DOS 1980-01-01
> 6. Windows 3.11 1980-01-01

This is the FAT file system date format, used also on FAT under Win9x,
WinNT, Linux, ...

This format is a bit packed calendar (year, month, day) format.

> 7. Microsoft.NET 0001-01-01

This is one of the .NET date formats. E.g. JScript.NET use a 64 bit
signed integer version of the unix fileformat, that mean value 0 is
1970-01-01. The OLE2 is also used, note that .NET is the OLE2
successor.

> 8. IBM Mainframes 1900-01-01 8 byte (64 bit) integer

So far I know, the IBM Mainframes use a packed decimal format with 4
bytes for date and 4 bytes for time:
hexadecimal: 0hhmmssF0cyydddF; 0 is binary 0000, F is binary FFFF,
hh: hours, mm: minutes, ss: seconds, ddd: day number (001-365),
yy: year in century (00-99), c: 0 = 19xx, 1 = 20xx, 2 = 21xx.

> 9. Lillian date 1582-10-14 8 byte (64 bit) floating point register.
> Gregorian Calendar started.

The Lilian Day (L.D.) is one of the day count systems, it count the
days since 1582-10-14. The most famous system is the Julian Day
(J.D.), which count the days from high noon at the first January 4713
BCE (Julian proleptic Calendar) = -4713-11-24T12:00:00 (Gregorian
proleptic Calendar). There are furthermore Julian Day derivates, e.g.
Chronological Julian Day (C.J.D.) or Dublin Julian Day (D.J.D.).

The Lilian or Julian Day number is a number, it can contain a fractal
part of the day or not. But there is not any binary standard for such
a date representation. Even if IEEE-754 Double Precision is a good
choice for this.

> ISO-8601 5.2.1.4 Expanded dates. "-YYYY-MM-DD" and "+YYYY-MM-DD" would
> require an epoch to handle "-9999-01-01".

Sorry, but it seem, that you don't have understand this chapter
correctly. It describe the possibility to extend the epoch by a
agreement. The example extend the epoch to -999999-01-01 ...
+999999-12-31.

It seem, you search for a suitable binary format. You should choose
such a format by the requirements of a application, not by a abstract
and in this case infinitely requirement.

How any other in this list wrote, ISO 8601 isn't a binary format
standard.

IMCO ISO 8601 is primary a standard for human writing and reading and
furthermore a standard for data exchange over text files. This standard
like to cover a maximum on requirements.

A binary format have other goals, it is not necessary neither
reasonable to implement a binary format with such wide requirement.

A binary format should reflect the requirement of the application.

> For calculating interval days fast the Gregorian date must be
> converted to days.

But this don't need necessarily a reflection of a day counting in the
binary format. Other continuous formats could be usefull.

> A 32-bit integer binary register can hold values from -214,783,648
> to +214,748.347

A 32 bit integer can hold 2^32 different values. If you use a signed
representation, this values could correspond to -2^31..2^31-1. Often
-2^31 represent a NULL resp. 'not a number' value. 2^31-1 is
2 147 483 647, not 214 783 648 or 214 748 347.

BTW: In a ISO discussion list, you should write a Number ISO-like,
ISO 31 prefer the , as decimal separator (alternativ .) and a space as
thousand separator.

> or a little more than 9 decimals digits(72 bits in decimal).

A decimal representation is a representation, not a binary value.
Value in the range of 0 to 2^31 - 1 need 31 bits, not 72.

> So this is no problem (±3,652,500 = ±10,000 years * 365.25 days per
> year).

> However, ISO8601 time-intervals are a problem for 32-bit binary
> computers. When time is added to dates and than converted to
> seconds, the number is too large for a 32-bit register computer.

But a 32 bit computer can calculate with nearly arbitrary wide values,
32 bit do mean, that many CPUs can only calculate 32 bit at once.

> That is the reason for these different epochs.

Not really.

E.g. DOS (FAT) use two 16 bit values, Windows use a 64 bit value
(resp. two 32 bit values), many UNIX versions have extend the file
timestamp by a second 32 bit value for microseconds or nanoseconds,
the OLE2 format use floating point value, ...

> However, most 32-bit computers support a 64-bit floating point
> register and therefore sometimes that is used. The mantissa in
> floating point registers uses bits, therefore the register can only
> support milli-seconds (.sss) as fractions of seconds.

This would be valid for a fixed point calculation, but not for
floating point. The absolute precision of a floating point value is
dependent of the value.

A millisecond precision is guaranteed for millions (10^6) years. Today
as Julian Day value have a precision of about 20 Microseconds. If you
change the 'Null-point' in the near of the current date you can
improve the current precision. Today in OLE2 format have a precision

In your range (-9999 .. +9999) a Double value should have a precision
of about 50 Microseconds, if you set 0 = 0001-01-01.

> The ISO-8601 specifications that looks like a momentous problem to me for a
> 32-bit computer that has no decimal register are:
> 5.5.4.3 Presentation of time-interval by its start and its duration
> "YYYY-MM-DDThh:mm:ss/PnYnMnDTnHnMnS"
> 5.5.4.4 Presentation of time-intervals by it duration and its end
> "PnYnMnDTnHnMnS/YYYY-MM-DDThh:mm:ss"
> "PYYYY-MM-DDTnHnMnS/YYYY-MM-DDThh:mm:ss"
> 5.5.6.3 Recurring time-intervals
> "Rn/YYYY-MM-DDThh:mm:ss/YYYY_mm_DDThh:mm:ss"

Sorry, but I can't detect any special problem. If you can store a
timestamp value, then you can store also a interval. If a single 32
bit register isn't sufficiently, than use two or more or use one and
the memory. You can use more than one arithmetic operation
consecutively to handle values with more bits than the processor
architecture have. Often I have calculate 32 bit values with a 8 bit
CPU and one year ago, even a 13466917 bit value with a 32 bit CPU.
However, my computer have need about 24 hours to convert this number
to a decimal value (String).

> A few of IBM's computers have decimal arithmetic registers. The US
> government often requires computers to support 31 decimals digits. They
> specify values of "31.0" to "31.15" digits, a standard for COBOL. For speed a
> computer needs a decimal register (a register that can do decimal arithmetic
> rather than binary arithmetic) for these size fields.

Binary arithmetic is always faster than decimal arithmetic (e.g. a
binary addition need only one tact cycle), at most you can use a more
complex hardware, that can calculate this with the same number of tact
cycles.

> Even the 64-bit binary computers can only handle a number of a
> little more than 19 decimal digits.

Significant decimal digits. Mostly not all digits of the date value
are significant.

> The fastest register in a computer is the unsigned integer registers
> (has only has positive numbers rather than the integer register that
> can have both negative and positive numbers).

There is not distinction between unsigned and signed for a register,
signed and unsigned are only different interpretations of the same
binary value. There is a difference by the arithmetic operations, but
there isn't any difference regarding speed in customary hardware.

> A 64-bit binary integer register can easily store as seconds the
> range of dates as seconds. Actual it is able to store hundredths of
> micro-seconds (sss,sss,sss,sss.sssssssss) (±10,000 years * 365.25
> days * 86400 second per day for ±3,652,500.99999999 range) or my
> preferred notation "f8".
> "-9999-01-01T00:00:00" to "+9999-12-31T23:59:59"

In this interval you can store the time value in 50 Nanoseconds
intervals, if you like.

> For speed purposes, it should be investigated if unsigned registers have any
> significant benefits. That would require:
> "-9999-01-01T00:00:00" have the value "1" I will explain latter.

> If a integer register is used than:
> "0000-01-01T00:00:00" should be zero

This two requirements are incompatible. Neither -9999-01-01 is the
day, which follow immediately after 0000-01-01, nor -9999-01-01 is a
day after 0000-01-01.

> Throughout history, men have repeatedly made the mistake of not
> providing for the value zero.
...
> ISO-8601 does not make provisions for unknown dates ...

Why should ISO-8601 do this? If you don't know the value, than you
cann't write any part of the date, the logical result is a empty
string (a value with no precision). Moreover many databases have
special flags to store NULL values.

> These two dates can be represented in an integer register:
> "0000-00-00" with a low value of 32 bits of ones "-2,147,483,648"
> "9999-99-99" with the high value 31 bits low order bits of ones value of
> "+2,14,483,747"

"0000-00-00" and "9999-99-99" are invalid date values, such values
aren't a good choice for a NULL value.

> These two dates can be represented if the unsigned register is used.
> "0000-00-00" with be 32 bits of zeros or the value zero.
> "9999-99-99" would be 32 bits of ones or the decimal value
> "18,446,744,073,709,551,615".

A unsigned 32 bit value can maximal be 4 294 967 295, which is the
decimal number, if all 32 bits are set to 1.

> The epoch should be:
> "-9999-01-01T00:00:00+16" for maximum speed in a binary computer to get
> UT (GMT) time.

You write many times over speed, I think you underestimate the real
performance brakes in a binary to text implementation. You try to
optimize on the unneeded locations.

However, what do you mean with epoch? Why do you use a invalid
timezone value +16?

> Rather than using seconds; if days and fraction of days were use
> (DDDDDDD,dddddddddddd) (7,305,000 days = 20,000 years * 365.25 days per year)
> than the accuracy could be increased to approximately hundreds of
> nano-seconds (.sssssssssss = .dddddddddddd fraction of a day). The one
> problem is that seconds cannot be converted to fraction of days in the binary
> numbering system.

But you can round the value to a enough precise value.

> 64 seconds than it would convert perfectly because these are powers of two.

You should suggest a calender reform. ;-)

> Maybe what is required, is a 32 bit unsigned integer standard with
> fraction of days (D,DDD,DDD.ddd) which will gives accuracy to the
> minute for epoch "0000-01-01" to "9999-12-31"

A integer with fraction? This is impossibly.

But you can multiply your day count with 24 * 60, than you get a
integer with minute precision. But then you need 33 bit to hold the
epoch "0000-01-01" to "9999-12-31".

BTW: I miss the handling of leap seconds and the handling of time
zones in your reflection, this are real challenges for a binary
format.

Bye Peter.
Your message has been successfully submitted and would be delivered to recipients shortly.