Subject | Re: [firebird-support] Date Range |
---|---|
Author | Lester Caine |
Post date | 2005-01-13T16:26:20Z |
Ivan Prenosil wrote:
I will not repeat your post, most of it has already been said and I
agree with.
I've done a reasonable amount of research now, and what I *AM* looking
for is a day count the same as firebird DATE, which can be reliably
matched to any calendar. The reference to ISO8601 means that we have a
standard way of displaying that day count, against which conversions to
other calendars can be reliably made.
I was just trying to confirm two things.
One - all the Gregorian rules are followed, so we can scale either way
beyond the arbitrary limits, and just take care when the conversion to a
string may go wrong.
Two - there are no other checks to prevent out of range values being
stored inside a DATE.
But that is now known (17 November 1858 = day 0)
The basic DATE casts will be used to provide a simple ISO8601 output for
data exchange, now that I know that they follow ALL the Gregorian rules,
and I need to work on providing conversions to other calendars.
I will probably use an INTEGER rather than DATE field and work with the
Julian day counts rather than 'firebird' offset ones. It is an agreed
standard, and all the currently available conversion tools work of that
basis, but I can still add the offset and CAST to ISO8601 strings.
Would this be too heavy a subject for a paper at the conference this
year? (It will be on?) I've got a lot of interesting stuff so far ;) and
adding the side issues on genealogical data might fill an hour.
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
I will not repeat your post, most of it has already been said and I
agree with.
I've done a reasonable amount of research now, and what I *AM* looking
for is a day count the same as firebird DATE, which can be reliably
matched to any calendar. The reference to ISO8601 means that we have a
standard way of displaying that day count, against which conversions to
other calendars can be reliably made.
I was just trying to confirm two things.
One - all the Gregorian rules are followed, so we can scale either way
beyond the arbitrary limits, and just take care when the conversion to a
string may go wrong.
Two - there are no other checks to prevent out of range values being
stored inside a DATE.
> The theoretical date range that could be stored in DATEBiased a couple of thousand years BC ;)
> is approximately 5.8 mil BC to 5.8 mil AD.
But that is now known (17 November 1858 = day 0)
The basic DATE casts will be used to provide a simple ISO8601 output for
data exchange, now that I know that they follow ALL the Gregorian rules,
and I need to work on providing conversions to other calendars.
I will probably use an INTEGER rather than DATE field and work with the
Julian day counts rather than 'firebird' offset ones. It is an agreed
standard, and all the currently available conversion tools work of that
basis, but I can still add the offset and CAST to ISO8601 strings.
Would this be too heavy a subject for a paper at the conference this
year? (It will be on?) I've got a lot of interesting stuff so far ;) and
adding the side issues on genealogical data might fill an hour.
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services