Subject Re: [firebird-support] Date Range
Author Ivan Prenosil
> From: "Lester Caine"
> All my dates will be ISO8601 with full years so now I can move to stage

ISO8601? You are not going to store dates as strings, do you ? :-)
You have to make distinction between
* Firebirds DATE datatype
* auxiliary built-in conversion routines for that datatype

The DATE datatype's format is absolutely independent on specific calendar.
E.g. if you select CURRENT_DATE, you will get the *value*
that can be interpreted as
13 / January / 2005 AD Gregorian
31 / December / 2004 AD Julian
2 / Thul Hijja / 1425 AH Hijri/Islamic
3 / Shevat / 5765 AM Jewish
4 / 12 / 4641 AC Chinese
Year 21 of Cycle 78 / Jiashen / Year of the Monkey Chinese
53383 Integer
D087 Hexadecimal

Because it is calendar independent, you do not have to worry
about things like leap years etc. - all operations with *dates*
(comparing dates, date arithmetic) will be always correct.
(To get correct results with *timestamps* you would
have to take leap seconds into account)

If you pass data values between client and server
as DATE datatype, then the Firebird does not care at all
what calendar or what ISO norm your client uses.

The theoretical date range that could be stored in DATE
is approximately 5.8 mil BC to 5.8 mil AD.

There is also built-in support for one specific calendar
type - the Gregorian calendar. The operations are
- conversion between DATE datatype and Gregorian-string value,
- extracting parts of Gregorian date using EXTRACT function
But it does not mean that you have to use these operations
(although they are handy e.g. when inserting date in sql script),
nor that concept of leap years means anything to the engine.

> Of cause in theory I need dates before the year 0100 - If I can find any
> ancestors dates from roman times ;)

As I said the actual range of DATE is several millions years,
the restriction to years 1 to 9999 is here only to avoid problems
with formatting of Gregorian date strings outside of this range.
But is it reasonable/fair to impose such restriction to DATE
instead of just adjusting those Gregorian-specific operations ?
(either raise exception or change formatting rules)