emacs-devel
[Top][All Lists]
Advanced

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

Re: The Emacs Calculator and calendar


From: Tim Cross
Subject: Re: The Emacs Calculator and calendar
Date: Mon, 8 Oct 2012 08:34:19 +1100

It seems to me this thread has gone a bit 'off the road' and is
perhaps trying to answer too many different things at once.

I thought the original post was asking if calc and the emacs calendar
should be using the same calendar definition. For consistency, I think
this should be yes. The question of what that calendar is and what
options could be added to allow the end user to select or specify
calendars or calendar parameters is possibly a different more complex
question requiring more analysis.

All the tools/facilities of emacs should use the same definiton - at
least then, if a user finds the result is incorrect, based on their
expectations, emacs will at least be consistently incorrect.

Tim

On 8 October 2012 07:32, Paul Eggert <address@hidden> wrote:
> On 10/07/2012 06:57 AM, Stefan Monnier wrote:
>
>> To the extent possible, Emacs could let the user specify the calendar
>> indirectly by instead specifying a "context" (a place, plus whatever
>> else is needed to resolve ambiguities), and then let Emacs figure out
>> which calendar was used at that time in that context.
>
> Yes, for example Emacs could examine (say) the TZ variable
> plus optional extra info.  This would work in theory, but in
> practice there would be many problems.
>
> For example, I live the Los Angeles area, and presumably
> Emacs would infer its calendrical behavior from my TZ
> setting 'America/Los_Angeles'.  But what behavior would that
> be, exactly?  To help answer that, here's L.A.'s calendrical
> history as best I know:
>
>   Settled by Tongva and Chumash thousands of years ago;
>   exact years not known.  These people used calendars, which
>   most likely did not agree with each other and varied with
>   time, but the details are not known.
>
>   Area first visited by Europeans in 1742.  The Cabrillo
>   Expedition anchored in San Pedro and Santa Monica bays for
>   one day each, then left and never returned.
>
>   Area visited again in 1602 by the Vizcaíno Expedition, which
>   also anchored for a couple of days and then moved on.
>
>   Next known visit by the Portolá Expedition of 1769.  These
>   are the first Europeans who are known to have set foot
>   near what became Los Angeles downtown, although there are
>   rumors of other visits before then.
>
>   City officially founded 4 Sept 1781 (Gregorian).
>
> Given the above, there are several problems in deciding how
> Emacs should behave for TZ='America/Los_Angeles':
>
>   Would its calendar change from "unknown" status to Old
>   Spanish status in 1542 and then switch to Emacs Julian in
>   1556 when Spain switched to Julian and then switch to
>   Gregorian in 1582, all because Spanish explorers' ships
>   dropped anchor nearby for a couple of days in 1542 and 1602?
>
>   Or should the Los Angeles entry stay "unknown" until 1781
>   because the city didn't exist until then?
>
>   Or should it do something else?
>
> No answer is satisfactory here -- whatever we'd put into the
> table would be wrong for some common uses.
>
> And Los Angeles is one of the *easy* cases.  There are
> hundreds of other locations to do, many of them much harder
> than Los Angeles, where we'd have worse problems, some
> technical and some political.
>
> Some other questions would come up too.  For instance:
>
>   What do we do when a calendar is partly known, but not
>   completely, as is the case for the Chumash calendar,
>   or for Julius Caesar's Julian calendar?
>
>   Should Emacs distinguish between "unknown" (that is, there
>   was a calendar but we don't know what it was exactly, as
>   in Los Angeles circa 1700) and "none" (that is, the area
>   was uninhabited and had no calendar, as in Los Angeles
>   circa 15,000 BC)?
>
>   We could make some simplifying assumptions, e.g., use the
>   Gregorian calendar when the actual calendar isn't fully
>   known, but how would this be reflected to the user?  And
>   if we're going to do that, why not just use Gregorian
>   everywhere, as that's simpler?
>
> I hope this helps to explain why adding a calendrical/locale
> database would be a big project, and why any attempts to
> build such a thing would run the risk hurting users (by
> giving them wrong or misleading answers) as much as help
> them.
>



-- 
Tim Cross



reply via email to

[Prev in Thread] Current Thread [Next in Thread]