Re: BUG #11883: Year 1500 not treated as leap year when it was a leap year
От | Tom Lane |
---|---|
Тема | Re: BUG #11883: Year 1500 not treated as leap year when it was a leap year |
Дата | |
Msg-id | 4926.1415374857@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #11883: Year 1500 not treated as leap year when it was a leap year (Bruce Hunsaker <hunsakerbn@ldschurch.org>) |
Ответы |
Re: BUG #11883: Year 1500 not treated as leap year when it
was a leap year
|
Список | pgsql-bugs |
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. 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. regards, tom lane
В списке pgsql-bugs по дате отправления: