This is whole story how date problem was and how Big DBMSs handled these problems.
> During the period between 1 A.D. and today, the Western world has
> actually used two main calendars: the Julian calendar of Julius Caesar
> and the Gregorian calendar of Pope Gregory XIII. The two calendars
> differ with respect to only one rule: the rule for deciding what a
> leap year is. In the Julian calendar, all years divisible by four are
> leap years. In the Gregorian calendar, all years divisible by four are
> leap years, except that years divisible by 100 (but not divisible by
> 400) are not leap years. Thus, the years 1700, 1800, and 1900 are leap
> years in the Julian calendar but not in the Gregorian calendar, while
> the years 1600 and 2000 are leap years in both calendars.
>
> When Pope Gregory XIII introduced his calendar in 1582, he also
> directed that the days between October 4, 1582, and October 15, 1582,
> should be skipped—that is, he said that the day after October 4 should
> be October 15. Many countries delayed changing over, though. England
> and her colonies didn't switch from Julian to Gregorian reckoning
> until 1752, so for them, the skipped dates were between September 4
> and September 14, 1752. Other countries switched at other times, but
> 1582 and 1752 are the relevant dates for the DBMSs that we're
> discussing.
>
> Thus, two problems arise with date arithmetic when one goes back many
> years. The first is, should leap years before the switch be calculated
> according to the Julian or the Gregorian rules? The second problem is,
> when and how should the skipped days be handled?
>
> This is how the Big DBMSs handle these questions:
>
> - Pretend there was no switch. This is what the SQL Standard seems to
> require, although the standard document is unclear: It just says that
> dates are "constrained by the natural rules for dates using the
> Gregorian calendar"—whatever "natural rules" are. This is the option
> that DB2 chose. When there is a pretence that a single calendar's
> rules have always applied even to times when nobody heard of the
> calendar, the technical term is that a "proleptic" calendar is in
> force. So, for example, we could say that DB2 follows a proleptic
> Gregorian calendar.
> - Avoid the problem entirely. Microsoft and Sybase
> set their minimum date values at January 1, 1753, safely past the time
> that America switched calendars. This is defendable, but from time to
> time complaints surface that these two DBMSs lack a useful
> functionality that the other DBMSs have and that the SQL Standard
> requires.
> - Pick 1582. This is what Oracle did. An Oracle user would
> find that the date-arithmetic expression October 15 1582 minus October
> 4 1582 yields a value of 1 day (because October 5–14 don't exist) and
> that the date February 29 1300 is valid (because the Julian leap-year
> rule applies). Why did Oracle go to extra trouble when the SQL
> Standard doesn't seem to require it? The answer is that users might
> require it. Historians and astronomers use this hybrid system instead
> of a proleptic Gregorian calendar. (This is also the default option
> that Sun picked when implementing the GregorianCalendar class for
> Java—despite the name, GregorianCalendar is a hybrid calendar.)
Source [1](
[To see links please register here]
) and [2](
[To see links please register here]
)