This is wrong. It does not account for dates prior to 1582. It also fails to use your programming environment’s built-in calendar arithmetic library, which is wrong by definition, even if your algorithm is correct.
For that matter, presuming 1582 for the Gregorian shift is wrong, if you are interested in historic calendar dates. It is locale dependent. For instance, 1752 was the year England switched. They also changed the beginning of the year from March 25 to Jan 1 at the same time, which your standard library may not reflect.
Yes, one should use the available date arithmetic routines, if they are available, and sufficiently aware for your purposes. Otherwise, realize that date and time manipulation routines are a bloody morass, not because of the computational complexity for any single rule, but because of the ad-hoc changing of rules by regional authorities.
1582? Damnable Papist! More than a few in the Christian world did not transition until 1700, and did not transition fully until 1776; the Orthodox Catholics in Greece didn’t change until 1923.
The larger question, though, is whether your air traffic control system needs to care that dates prior to its creation may or may not be considered ‘leap’ depending on where it is eventually shipped.
Everything you say is true, but 32 years of no middle name and a surname with a space in it have taught me never to underestimate the laziness and ignorance of programmers!
(No offense intended, I’m a programmer myself).
The timeline of Gregorian adoption is very piecemeal:
And Sweden is a really complicated special case:
Yeah, many applications will (thankfully) not have to consider historical dates. Many WILL, however, have to consider DST switches, which modern governments have a penchant for messing with the rules for.
The Java GregorianCalendar class assumes October 5, 1582 by default, but has a method which you the programmer can set the change date to match which country your application is meant to represent.
Word of warning though, “However, dates obtained using GregorianCalendar are historically accurate only from March 1, 4 AD onward, when modern Julian calendar rules were adopted.” If you need a Calendar calculator more accurate than that, you’ll need to go seek out a third-party library.
Don’t get me started on the proper use of floating timezones.
It also notes:
That isn’t accurate. The changeover from March 25 to Jan 1 was made independently of the Gregorian changeover in many countries, often before the adoption of the Gregorian calendar. Accommodating that was a headache that the implementer of GregorianCalendar chose to punt on, and I don’t blame them.
However the abstract java Calendar object provides a reasonably good definition for implementing calendar variants and hiding the considerations from the application programmer, provided you aren’t straying too far from the “12 months per year / 7 days per week” structure. You can actually manage to do date arithmetic with the thing in a semi-sane fashion, once you get the hang of it.
Googling turned up this page of anecdotes. It seems lots of mothers have tried to fiddle the date to avoid having a leap-year baby. I have no idea why - I think it would be a neat talking point.
All you really need is a couple of functions to convert to and from Julian days (or any other simple linear timekeeping standard).
You have to be careful with using such a representation to perform arithmetic, though - one class of date bugs arises when somebody decides to calculate something like a one day interval (when you really mean “same time tomorrow”) by adding 86400 seconds to the current system time. If it crosses DST, you may want to add 23 hours or 25. If you don’t have a calendar object that directly handles date arithmetic, you have to muck around with today’s date to convert it, rather than something like:
cal.setTimeInMillis(System.currentTimeMillis());
cal.add(Calendar.DAY_OF_MONTH,1);
long wakeup = cal.getTimeInMillis();
The calendar object now takes care of you.
ETA:
Note that “time” in these java method names really means time and date, as ms since epoch.
On the other hand, you might also have something you really do want to do 24 hours from now, regardless of DST. You just have to be careful about that sort of thing; no system is going to read your mind.
Understood. But the point is that an object or set of library routines to handle setting, adding, subtracting days, hours, etc while hiding DST / leap year / locale nastiness saves you a lot of headache. Particularly if you wind up writing stuff that handles user specified scheduling. Of course, I might also mention that my example would probably be more realistic using an actual time specification corresponding to the last event instead of System.currentTimeMillis(). If you calculated it that way as part of handling the scheduled event, the time would drift by the ms. to process your event each time. Not to mention having to be sure you don’t do something weird if the user changed their clock.
My ex husband was born on the 29th of Feb, and was in the Navy, so the government of Oregon and the US government both had no issues with it as a date.