unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: The Emacs Calculator and calendar
Date: Mon, 8 Oct 2012 08:34:19 +1100	[thread overview]
Message-ID: <CAC=50j-xfB=xhJxh7TJdKemJBrMM6+6k1UaFY-s3Mho+xJgEtw@mail.gmail.com> (raw)
In-Reply-To: <5071E6E7.7080906@cs.ucla.edu>

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 <eggert@cs.ucla.edu> 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	other threads:[~2012-10-07 21:34 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-05 19:13 The Emacs Calculator and calendar Jay Belanger
2012-10-05 19:24 ` Paul Eggert
2012-10-05 20:51 ` Edward Reingold
2012-10-05 21:14   ` Pascal J. Bourguignon
2012-10-06 15:41   ` Richard Stallman
2012-10-06 22:07     ` Paul Eggert
2012-10-07  3:49       ` Richard Stallman
2012-10-07  6:22         ` Paul Eggert
2012-10-07 17:30           ` Richard Stallman
2012-10-07 18:23             ` Paul Eggert
2012-10-10  3:37               ` Richard Stallman
2012-10-07  6:36       ` Eli Zaretskii
2012-10-07  7:50         ` Paul Eggert
2012-10-07  8:45           ` Eli Zaretskii
2012-10-07 13:01             ` Juanma Barranquero
2012-10-07 14:08               ` Eli Zaretskii
2012-10-07 17:30           ` Richard Stallman
2012-10-07 17:57             ` Juanma Barranquero
2012-10-07 21:55         ` Sam Steingold
2012-10-08 13:39           ` Richard Stallman
2012-10-07  8:17       ` Stephen J. Turnbull
2012-10-07  7:56     ` Achim Gratz
2012-10-07  8:44       ` Eli Zaretskii
2012-10-07 13:57         ` Stefan Monnier
2012-10-07 20:32           ` Paul Eggert
2012-10-07 21:34             ` Tim Cross [this message]
2012-10-08  0:32             ` Stefan Monnier
2012-10-08  6:30               ` Paul Eggert
2012-10-08  7:28                 ` Ulrich Mueller
2012-10-08 13:56                   ` Stefan Monnier
2012-10-08 14:49                     ` Jay Belanger
2012-10-08  8:21                 ` James Cloos
2012-10-08 14:59                 ` Jay Belanger
2012-10-13  6:02                   ` Paul Eggert
2012-10-13 14:05                     ` Jay Belanger
2012-10-08 13:39             ` Richard Stallman
2012-10-08 19:34               ` Paul Eggert
2012-10-08 22:39                 ` Richard Stallman
2012-10-09  6:28                   ` Paul Eggert
2012-10-09 15:47                     ` Richard Stallman
2012-10-09 23:10                       ` Paul Eggert
2012-10-10  2:22                         ` Jay Belanger
2012-10-11 12:09                           ` Jason Rumney
2012-10-12  1:52                             ` Richard Stallman
2012-10-10  3:37                         ` Richard Stallman
2012-10-10 21:42                   ` Christoph Herzog
2012-10-05 21:17 ` Edward Reingold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC=50j-xfB=xhJxh7TJdKemJBrMM6+6k1UaFY-s3Mho+xJgEtw@mail.gmail.com' \
    --to=theophilusx@gmail.com \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).