× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



** Warning ** You are entering into a discussion area my wife refuses to allow me to participate on in social settings due to my tendency to bore people to tears with my droning on and on with the topic of calendars :-)

You are correct that the date and timestamp support in DB2 for i5/OS is limited to the year range of 0001 AD to 9999 AD. This is due to the Data Definitional Attribute List (DDAT) used by DB2 for i5/OS -- which is known as the SAA calendar. The system however does not have this limitation. You can define DDATs that support years prior to 0001 AD. You can also define DDATs that support more limited year ranges (for instance, only from 1940 AD to 2039 AD which as been done by some parts of i5/OS as part of their current implementation for 2-digit years). See http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/rzatk/MINDTCON.htm for a general review of what the system can do when not limited by DB2 for i5/OS SAA implementation details.

As for not for not accounting for the adoption of the Gregorian calendar, that is one difficult item to handle (as I'm sure you are aware). October of 1582 was the adoption date for Spain, Portugal, and some parts of Italy, but many of the other Catholic countries in Europe waited until 1583 and/ or 1584 (with the actual day of adoption in each year varying significantly). Russia didn't adopt the Gregorian calendar until 1918 and the Greek Orthodox Church until 1924 (though Greece did in 1923). Protestant countries tended toward the 1700s with Great Britian adopting the Gregorian calendar in 1752. As the United States at that time was a colony of Britian, 1752 was also the adoption date for what is now known as the United States. In this case September 2 1752 was followed by September 14 1752. So for the majority of the world, the %diff between 1582-10-15 and 1582-10-04 would indeed be 11 days.

Bruce Vining
Bruce Vining Services

Dave Kahn <dkahn400@xxxxxxxxxxxxxx> wrote:
On 17/12/2007, Adam Glauser wrote:
Peter.Colpaert@xxxxxxxxx wrote:
Just a thought: could date fields be used for dates before Christ
(theoretically speaking of course, I'm fully aware that calendars have
changed many times in the past)

rob@xxxxxxxxx wrote:
Who gives a shit? Take it to CPF0000 unless you have a valid business
reason for caring.

Just because you don't care doesn't mean no one does. Think museums,
universities ... I know there are at least a few people from educational
institutions that read this list. It's certainly a valid question.

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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.