Re: [Scheme-reports] current-posix-second is a disastrous mistake Ray Dillinger (16 Dec 2010 09:37 UTC)

Re: [Scheme-reports] current-posix-second is a disastrous mistake Ray Dillinger 16 Dec 2010 09:35 UTC

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.

				Bear

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports