- 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

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.

>

> Yahoo! Groups Sponsor

>

>

>

> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

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

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 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 subject of this list.

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

> Some current time epochs are:

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

> 1. Unix 1970-01-01 it is a 32 bit signed integer. Will overflow 2038-01-19

> 03:14:07

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

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

> 6. Windows 3.11 1980-01-01

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.

The Lilian Day (L.D.) is one of the day count systems, it count the

> Gregorian Calendar started.

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

Sorry, but it seem, that you don't have understand this chapter

> require an epoch to handle "-9999-01-01".

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

But this don't need necessarily a reflection of a day counting in the

> converted to days.

binary format. Other continuous formats could be usefull.

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

A 32 bit integer can hold 2^32 different values. If you use a signed

> to +214,748.347

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

But a 32 bit computer can calculate with nearly arbitrary wide values,

> 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.

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

This would be valid for a fixed point calculation, but not for

> 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.

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

of about 600 Nanoseconds.

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

Sorry, but I can't detect any special problem. If you can store 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"

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

Binary arithmetic is always faster than decimal arithmetic (e.g. a

> 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 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

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

> little more than 19 decimal digits.

are significant.

> The fastest register in a computer is the unsigned integer registers

There is not distinction between unsigned and signed for a register,

> (has only has positive numbers rather than the integer register that

> can have both negative and positive numbers).

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

In this interval you can store the time value in 50 Nanoseconds

> 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"

intervals, if you like.

> For speed purposes, it should be investigated if unsigned registers have any

This two requirements are incompatible. Neither -9999-01-01 is the

> 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

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" and "9999-99-99" are invalid date values, such values

> "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"

aren't a good choice for a NULL value.

> These two dates can be represented if the unsigned register is used.

A unsigned 32 bit value can maximal be 4 294 967 295, which is the

> "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".

decimal number, if all 32 bits are set to 1.

> The epoch should be:

You write many times over speed, I think you underestimate the real

> "-9999-01-01T00:00:00+16" for maximum speed in a binary computer to get

> UT (GMT) time.

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

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

> (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

You should suggest a calender reform. ;-)

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

> Maybe what is required, is a 32 bit unsigned integer standard with

A integer with fraction? This is impossibly.

> fraction of days (D,DDD,DDD.ddd) which will gives accuracy to the

> minute for epoch "0000-01-01" to "9999-12-31"

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.