[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] current-posix-second is a disastrous mistake

On Wed, 2010-12-15 at 14:49 -0500, John Cowan wrote:

> > If you want to work with calendar datetimes then you shouldn't be
> > converting them to seconds at all.
> If you are working with non-Gregorian calendars, you need to be able
> to pivot date-time values through something, and a count of calendrical
> seconds is a very sensible option.

As someone who's done some calendar-conversion software before, I 
have some input here. 

The standard usually used as a pivot for calendrical conversions
(and increasingly in all astronomical software) is the Julian Day
Number, which is the real number of days since the proleptic 
Julian calendar marked January 1, 4713 BC, at Greenwich noon. 
(note, the proleptic Gregorian Calendar marked the same date a bit 
over a month later). 

Wikipedia Article (accurate, to a knowledgeable but cursory reading)
is http://en.wikipedia.org/wiki/Julian_Day/ .

This is the standard used for astronomical timekeeping; These days 
are as perfectly synchronized to the rotation of the earth as 
astronomical observations can make them. They are not based on 
the count of seconds, at all.  

The Astronomical Union declares a leap second when the clock needs 
a correction so that its days can run in closer syncrhonization to 
the Julian Day Number. 

If you want a simple date format that allows days and fractions-of-
days etc to be added, subtracted, worked with, etc, as calendrical 
time, the Julian Day Number is the single obvious choice.  What you
store is a real number; how the number is interpreted depends on 
what calendar and civil clock you are applying to it.  It is 
explicitly a count of planetary revolutions relative to the sun, 
and as long as people keep their civil clocks synchronized to days, 
it will be a (the?) base measurement for civil date and time.
This is the day of which a POSIX second badly approximates 1/86400th. 

So, I'm going to reiterate the suggestion I made earlier.  Let the 
clock function return the real number of seconds since the Unix 
epoch, and let the date function return the real number of days 
since the Julian-Day-Number epoch, and document them both so 
that people can be aware that not every day is exactly the same 
number of seconds long. 


Scheme-reports mailing list