On Tue, Apr 20, 2010 at 10:59 AM, Dave Rolsky <auta...@urth.org> wrote:
> I'd _really_ like to see this be based on Rata Die, which is January 1, > 0001. See http://en.wikipedia.org/wiki/Rata_Die > To be clear, that's specifically January 1, 1 CE in the retrojected Gregorian calendar, which is the same day as January 1, 3 CE in the retrojected Julian calendar; noon UTC began Julian Day 1,721,426. You could also use the JD directly, but there's a subtle design decision lurking there. The JD is tied to UTC, and refers to a specific 24-hour period that is the same across the planet: JD 2,455,307 began 4 hours and 45 minutes ago as I write this, and will be over in 19 hours and 15 minutes, and that is a universal fact no matter whether it's currently Tuesday the 20th or already Wednesday the 21st where you are. An RD, in contrast, is not tied to a specific time zone, but is simply a numerical way to represent exactly the same concept as the date: whatever the Gregorian date "April 20, 2010" means, "RD 733,882" means the same thing. So on some parts of the planet its RD 733,882 and in others it's already RD 733,883. The RD is thus a better fit for the Date class, which is a representation of an abstract date, unanchored in spacetime. An integral JD number may be used to fit the same bill, but opens the possibility of confusion with the more typical anchored JD values (which might even be available from DateTime objects). The difference between them, or with any other epoch choice, is mostly just a matter of a constant which can be added or subtracted as needed, and to the degree that's true this is just bikeshed painting. But the part that isn't is important: I don't want to dilute what I see as the primary benefit of a Date object over a DateTime object that simply has its time fields zeroed, which is flexibility. The latter is still by implication tied to a specific swath of spacetime (e.g. midnight to midnight in some time zone), whereas the former is free to refer to whatever the human date designation can. -- Mark J. Reed <markjr...@gmail.com>
