Re: BUG #11883: Year 1500 not treated as leap year when it was a leap year
От | Bruce Momjian |
---|---|
Тема | Re: BUG #11883: Year 1500 not treated as leap year when it was a leap year |
Дата | |
Msg-id | 20141111015637.GB27554@momjian.us обсуждение исходный текст |
Ответ на | 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 Fri, Nov 7, 2014 at 10:06:26AM -0500, Tom Lane wrote: > 5. A side issue that's probably pretty relevant for the OP's application > is that not every country adopted the Gregorian calendar at the same time. > Really if he wants any data integrity he's going to need to store an > explicit indication of whether a date is in Julian or Gregorian calendar. > (In a world of infinite manpower you could imagine extending the zic > database to provide information about which calendar was used when in > every region, but I don't see us going there.) Oh, it is worse than the date of the switch to Gregorian --- Russia had some really odd calendars: http://novaonline.nvcc.edu/eli/evans/his241/Notes/Calendar.html So, roughly speaking, in the nineteenth century, the Russian calendar was 12 days behind the Western European calendar. http://en.wikipedia.org/wiki/Soviet_calendar The Soviet calendar added five- and six-day work weeks between 1929 and 1940 to the Gregorian calendar adopted by Russia in 1918. Many Russian events, even those in the 20th century, have multiple dates for a single day/event, based on the calendar system used. We could figure out a way to relax our code to allow for leap year handling for pre-1582 dates, but the larger issue is that date calculations would also be affected by the existance of such Julian-only leap days, whether you stored those dates or not, meaning this change would affect everyone, not just those who want to store such dates. For example, should: SELECT '1500-03-01'::date - '1500-02-28'::date; return 1 or 2? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-bugs по дате отправления: