Programmers universally compute the number of days between two dates by determining the seconds of the two dates (by using a function such as getTimeInMillis() for each date), computing the difference in seconds between the two dates, and dividing the difference by 86,400.
I proved this to myself by performing the following experiment with three of Java's date classes, GregorianCalendar, Date, and ZonedDateTime. In pseudocode: For year = 1997 to 2015 Date1 = year, month =1, day =1, hour = minute = second =0 Date2 = year+1, month =1, day =1, hour = minute = second =0 Duration = Date2 - Date1 (in seconds) Print Date1, Date2, Duration Date1 = 1997, month =1, day =1, hour = minute = second =0 Date2 = Date1 + 31_536_000 * 18 + 4 * 86_400 //Add 18 yrs (in secs) + 4 days for leap years Print Date1, Date2 For each of Java's date classes, the Duration was equal to 31,536,000 seconds (= 365 * 86,400) for all years except leap years, when the duration was 31,622,400 (=31,536,000 + 86,400) for 366 days. In the second part, Date1 = Jan 1, 1997 and Date2, which was equal to Date1 plus 18 years of 31,536,000 seconds per year + 4 leap days, equaled Jan 1, 2015. But we know that the duration in seconds of 1997, 1998, 2005, 2008, and 2012 was actually 31,536,001 seconds because each of these years had a leap second added. So, why does it work? Java, at least, is pretty upfront about why it works. Java describes ZonedDateTime (and its various cousins Instant, LocalDateTime, and OffsetDateTime) as implementing a proleptic calendar, where in this case proleptic means what the data and time would have been in times past if they had been using our calendar system. In addition, the Java documentation implies that the new date/time classes (ZonedDateTime, Instant, LocalDateTime, and OffsetDateTime) cannot be used for astronomical calculations. Why? Because they won't be correct. Jan 1, 2015 minus 18 years of 31,536,000 seconds per year - 4 leap days * 86,400 seconds will not produce the time a computer would have indicated on Jan 1, 1997; instead, there will be 5 seconds difference for the 5 leap seconds introduced in that interval. Oracle's justification for their approach is: "Given the complexity of accurate timekeeping ..., (the) Java API defines its own time-scale, the Java Time-Scale. "The Java Time-Scale divides each calendar day into exactly 86400 subdivisions, known as seconds. These seconds may differ from the SI second. It closely matches the de facto international civil time scale, the definition of which changes from time to time. "The Java Time-Scale has slightly different definitions for different segments of the time-line, each based on the consensus international time scale that is used as the basis for civil time. Whenever the internationally-agreed time scale is modified or replaced, a new segment of the Java Time-Scale must be defined for it. Each segment must meet these requirements: ."the Java Time-Scale shall closely match the underlying international civil time scale; ."the Java Time-Scale shall exactly match the international civil time scale at noon each day; ."the Java Time-Scale shall have a precisely-defined relationship to the international civil time scale." (Source: Oracle documentation for the java.time.Instant class.) In other words, the only aspect of time that matters to Java is that the clock, in the present, be perfectly accurate each day at noon. Thus the time Java displays and uses will be accurate, and up to spec, if and only if the user's clock is accurate. BTW, proleptic can be defined as: The representation or assumption of a future (past?) act or development as if presently existing or accomplished. (http://www.merriam-webster.com/dictionary/prolepsis, parentheses added) Proleptic calendar, a calendar that is applied to dates before its introduction. (http://en.wikipedia.org/wiki/Proleptic) Hope this helps. Charles Elliott _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions