The seconds problem - redefined

Dar Scott dsc at swcp.com
Thu Apr 15 23:34:38 EDT 2004


On Thursday, April 15, 2004, at 06:56 PM, Rob Cozens wrote:

> How can routines to store, sort, and otherwise manipulate dates be 
> "calendar independent"?

I didn't say that well.  Maybe because I'm still sorting it out in my 
mind.

We don't travel close to the speed of light, so time can be thought of 
as independent of location and any calendar.  The mean length of a 
solar day is pretty well constant, but I guess that can be considered 
on a year by year basis.

If we consider time by day and fraction of a day from some event in the 
past, that can be translated to some calendar and clock scheme.  For 
example, we might consider days from some time Jan 1 4713 BC at some 
location.  That can be translated to a date using some calendar scheme 
such as Julian or Gregorian.  A composite scheme using location might 
be used.  Time zone and daylight savings schemes can be added.  
Calendars must also consider when the day changes, typically, midnight, 
noon, sunrise or sunset.  A historian might compare dates recorded in a 
variety of calendars.

We might want to consider dates without thinking of timezones and the 
like, too.

Some candidates for zero time:
Midnight GMT Jan 1 4713 BC
Noon GMT Jan 1 4713 BC
Midnight GMT Nov 17 1858
Midnight GMT Dec 30 1989
Midnight GMT Jan 1 1900
Midnight GMT Jan 1 1970

The problem with the term "Julian Date" it that it is ambiguous.  It 
can mean a date in the Julian calendar, the western calendar before the 
Gregorian calendar.  It can mean the Julian day number after Scaliger's 
Julian period.  In some cases it can even mean the date written in some 
form with the day-of-year and year number and has nothing to do with 
either of the above.  It might even have other meanings.  I think the 
latter is the one you are using.

Knowing the calendar scheme one can convert to and from a day number.  
Knowing a day number, one knows the day unambiguously.  For example, in 
any location the daylight savings scheme might change next year.

I guess what is needed as a basis is a good day number.  After that is 
calendar translations.  Gregorian must come first.  Then time zone.  
Then some daylight savings schemes.  Then other calendars.  Then 
automatic switching of calendars.  Maybe some specialized translations. 
  All of these can be based on the day number.

There are (no doubt) ways to do the same kind of thing other ways.

Dar Scott



More information about the use-livecode mailing list