Re: BUG #11883: Year 1500 not treated as leap year when it was a leap year

Поиск
Список
Период
Сортировка
От Bruce Hunsaker
Тема Re: BUG #11883: Year 1500 not treated as leap year when it was a leap year
Дата
Msg-id 20141107155144.GH4482@gr8.dev
обсуждение исходный текст
Ответ на Re: BUG #11883: Year 1500 not treated as leap year when it was a leap year  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On 07 Nov 14 10 40, Tom Lane wrote:
> Bruce Hunsaker <hunsakerbn@ldschurch.org> writes:
> > Just to add some additional background, We were migrating data from
> > an Oracle DB when we hit this. Oracle's dates are Julian based
> > and range from Jan 1, 4712 BCE to Dec 31 9999 CE.  So Feb 29, 1500
> > is a valid date in an Oracle Date type (Julian day 2268992).  So I
> > wonder what the rules might be to convert a Julian date to a
> > 'proleptic Gregorian' date (pre 1582) and vice versa?
>
> I think you have a bigger data-integrity problem than you realize.
> Perhaps I'm jumping to conclusions based on your return address,
> but I suppose what you've got here is a database of historical
> birth and death records from lots of different countries?  Your
> problem, as I mentioned upthread, is that you're going to need some
> context to figure out whether any given recorded date was meant as
> Julian or Gregorian.  If you don't know that for sure, applying a
> transformation that's only going to be right for 80% or 90% of your
> data will make things worse not better.

I was thinking the same thing after my last post.

> In the short term you'd probably be best off just storing the Oracle
> output as text.  You could consider converting it to some type with
> stronger semantics later, but you'll have enough on your plate
> making the switch at all.

That's an excellent suggestion. I'm going to advise that we store the
Oracle output as text, so the original value gets preserved.

--
Bruce Hunsaker


 NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and
privilegedinformation. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intendedrecipient, please contact the sender by reply email and destroy all copies of the original message. 

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #11883: Year 1500 not treated as leap year when it was a leap year
Следующее
От: dimon99901@mail.ru
Дата:
Сообщение: BUG #11903: Segmentation fault