Peter J. Holzer wrote: > On 2007-07-03 05:12, Scott David Daniels <[EMAIL PROTECTED]> wrote: >> TOPS-20 did an interesting format which suggest an interesting variant: >> Tops-20: 36-bit (the machine word size) fixed-bit representation >> of days since a given moment (the first Photographic >> plates of the sky). The "binary point" was at the middle >> of the word; the low order 18 bits were the time of day >> (GMT), the high-order 18 bits were the days-since date. >> I think there's a definite practical advantage in storing dates as a day count from a base date and providing a standard set of procedures/methods to convert it to and from a human-readable format. It makes all sorts of date calculations much easier. For instance, if there's a requirement to produce statements dated for the last day of the current month the pseudo code is simply: - convert the date to ccyymmdd format - add 1 to the month, adjusting the year and century to fix year roll-over and set the day to 1 - convert back to day count and subtract 1 - the result, output in readable form is the last day of the month irrespective of month length, leap years, etc.
I don';t think it matters what the base date is, though the Astronomical base date [12 noon on 1 JAN -4712 (4713 BC)] may be as good as any. Other bases I've seen (apart from UNIX date) are ICL 1900 mainframes, which set day zero as 31 Dec 1899 and held the time separately. ICL 2900 systems held the date and time as microseconds since 00:00:00 1900-01-01 in a 64 bit word, which is also easy to deal with and allows the same set of date arithmetic operations as a straight day number. BTW, be sure to distinguish Julian Day and Modified Julian Day (used by astronomers from the "Julian Date" that [used to] be used by IBM mainframes. The former is a day count but the latter is day within year (yyddd). JD and MJD are described in: http://tycho.usno.navy.mil/mjd.html -- martin@ | Martin Gregorie gregorie. | Essex, UK org | -- http://mail.python.org/mailman/listinfo/python-list
