RE: [Evolution] Islamic Calendar Support File (Progress!)

["Ray Lee" <ray madrabbit org>]

Russell Steinthal wrote:

> If that's the case, what *is* the recommended way of handling dates
> prior to 1970?

As Dan Winship points out, use a struct tm. That's not a panacea, mind
you, as even it pegs at January 1, 1900, but it gets you closer. Anything
much before, hmm, 1750 or so [1], really shouldn't appear on a western
calendar, as there's no unified Gregorian scheme before this time.

This is, of course, problematic for cultures that have been hanging around
a tad longer than us Westerners. (Y'know, like pretty much all of them?)

The most sane way I've seen is to migrate to a nice, dead calendar, such
as the Julian one, whose epoch is fixed at January 1, 4713 BC at noon, and
count days. (The Julian calendar is more astronomically based than others,
and hence counts days from noon to noon. This introduces a 0.5 day offset
you'd need to take into account.) The Julian date as I write this is 991
054.

   [1] Even though the Gregorian calendar had been created nearly
       two full centuries prior, it took an act of parliament to
       get it to be adopted. By which time there had been enough
       drift that to account for the seasons, people lost eleven
       days out of their 'lives.' This caused riots. Once wouldn't
       expect the history of something as mundane as a calendar to
       be fraught with blood and violence, but there ya go.

       People go ahead and make Gregorian dates for events prior
       to this anyway, but they have the grace to label the
       calendars 'proleptic' to point out that they're
       extrapolating.

> It can't be the case that Unix/libc can't store dates
> prior to the Epoch, but without negative time_t's, I'm at a loss as
> to how to do it.

Got me when it comes to [g]libc. If you're really interested in storing
dates and times prior to 1900, I'd do the iCal time format. If you want
just dates, and back to antiquity, use Julian days. Otherwise, do a struct
tm and wait for the libc people to update time_t to a long long. If they
do, it'll break a truckload of code, though, I'm sure...

> (If it is, it is a perfectly good reason, in my
> opinion, to reimplement the time functions.  I suppose we could
> simply disallow appointments prior to 1970 (since they could only be
> archival anyway), but that seems a less than ideal situation.)

Agreed. Another perfectly good reason is when insurance companies start
trying to do amortization charts past Tuesday, January 19th, 2038, 3:14:07
AM GMT. (Of course, I'm speaking loosely. Insurance companies have already
hit this problem, and have fixed it by doing their own time handling, but
I'm sure you get the point of the example.)

[Why an EvolutionTime type?]
> It will just be something like:
> typedef struct { time_t t; EvolutionTimeZone* tz; } EvolutionTime;

Cool, looks fine.

> where tz points into a global timezone database.  (That part we need
> to reimplement, since the iCalendar spec allows the creation and use
> of arbitrary timezone definitions, so we can't rely on the libc
> timezone database.  It sucks, I know, but I didn't write the spec.)

Yeah I know, but you really have to allow for any kind of timezones. It's
even worse than that though. Some damn US city actually doesn't go onto
daylight savings time come the switchover date. Instead, since they happen
to be stradling a timezone line, they pop themselves over to the other
timezone, then back again six months later.

Dorks.

Ray Lee / ray madrabbit org ~ rblee impulse net