Re: To Date or Not to Date... that is the question

Hi Dave

Long time since your time in Uzbekhistan or wherever you used to be! At least, I'm assuming you're the same guy!

DSPFFD actually kind of lies to us when giving the lengths of dates/times/timestamps. It reports the external lengths - internal is a different story.

From the RPG manual---

A date is a three-part value (year, month, and day) designating a point in time under the Gregorian calendar, which is assumed to have been in effect from the year 1 A.D.

Note the assumption of the Gregorian calendar going all the way back. So IBM has rewritten history probably for simplicity of something or other.

I think someone mentioned that dates are not stored as ISO or any other format, rather as something like a Scaliger number. I found a nice enough discussion of this at http://www.sizes.com/time/dayJulianr.htm

Turns out that the Scaliger number is the number of days, including fractions, since noon on January 1, 4713 BCE and is based on a period of 7980 years in which 3 cycles of measuring time never have the same triplet of values. See link above.

IBM seems to take the starting point as midnight on that oh, so remote date, and calculates everything as if Gregorian - our current calendar.

The internal representation of a date is a string of 4 bytes that contains an integer. The integer (called the Scaliger number) represents the date.

"select hex(current date) from sysibm/sysdummy1" yields 002573B5 in hex or 2,454,453 in decimal.

Times and microseconds are both stored in a packed format - 6 digits in 3 bytes - not the packed type we are used to. So a timestamp occupies 10 bytes in the internal representation.

"select hex(current time) from sysibm/sysdummy1" yields 100455

"select hex(current timestamp) from sysibm/sysdummy1" yields 002573B5100516343995

I just tried putting an integer 5 less than the earliest date (0001-01-01) into an integer field of one file, then copying that file to another with a date in the respective field, fmtopt(*nochk) - got data mapping errors like crazy. So the system translates at several stages, it seems - no way here to express dates BCE.

I also tried subtracting 5 days from that earliest date - got a bunch of question marks - heh!

Dates BCE COULD be handled, as this so-called Scaliger number is sufficient to do it. But it seems there is not much of a business need to do so, but for those few historians among us - and astronomers.

Well, it's obvious I have too much time on my hands - am on vacation!!

Done rambling!
Vern

At 06:25 AM 12/18/2007, you wrote:

-snip-

Of course it's a valid question and I also fail to understand the
vitriolic response. And the answer is no. The representation in the
database of an ISO date field requires 10 characters. The first 4 are
the year and there is no provision for representing a negative year. A
date calculation in ILE RPG resulting in a date before 0001-01-01 will
generate an overflow or underflow exception.

If you want to calculate the duration between two historical dates you
should also be aware that date calculations in RPG do not take the
adoption of the Gregorian calendar into account. October 4th 1582 was
a Thursday in the Julian calendar. Ten days were skipped so that the
following day was declared to be Friday October 15th. In ILE RPG the
%diff between 1582-10-15 and 1582-10-04 is incorrectly (from a
historical perspective) calculated as 11 days instead of 1 day.

--
Dave...