From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: The Emacs Calculator and calendar Date: Mon, 8 Oct 2012 08:34:19 +1100 Message-ID: References: <87y5jk3f7d.fsf@gmail.com> <87626md8aj.fsf@Rainer.invalid> <83vcem6592.fsf@gnu.org> <5071E6E7.7080906@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1349645667 10369 80.91.229.3 (7 Oct 2012 21:34:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Oct 2012 21:34:27 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 07 23:34:33 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TKyUZ-0003w7-1J for ged-emacs-devel@m.gmane.org; Sun, 07 Oct 2012 23:34:31 +0200 Original-Received: from localhost ([::1]:55295 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKyUS-0003DQ-QV for ged-emacs-devel@m.gmane.org; Sun, 07 Oct 2012 17:34:24 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKyUQ-0003DI-JA for emacs-devel@gnu.org; Sun, 07 Oct 2012 17:34:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TKyUP-0002HW-0z for emacs-devel@gnu.org; Sun, 07 Oct 2012 17:34:22 -0400 Original-Received: from mail-vb0-f41.google.com ([209.85.212.41]:43076) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKyUO-0002HR-SJ for emacs-devel@gnu.org; Sun, 07 Oct 2012 17:34:20 -0400 Original-Received: by mail-vb0-f41.google.com with SMTP id v13so4149545vbk.0 for ; Sun, 07 Oct 2012 14:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2EzIPBU8xgff7OnKlckUlOEMPjRee9ONBDJy6PzPt4Y=; b=wjHRZKnlVxIa1WBBBb5U9asC185sjouW9DWHrG7Unc14JFkdN4MKZxfQoT5xs/L2CZ l9sjippkvEVRd83gbPqkN3tVY80Bu0Nfktm1RX/4bVwmkbRYsZPSNBBIsyQ7uRWg0pS1 7XJwC2dxE4dQQArfQ2DqEyBoinXfli4U+cqbIGCmpwvpXHtb36rAxtRQ2TIX0NAdgxqR j7s6TRTk6WMbtDpbuCz70xCB5h18mtMSXSkWaLh9w/BUwJKhjHYVfRs9iD5Q56KQaDuH 6hghplOtLiVWqB8ydG1VuCkwI6A/c0R4T2+qr4GegcZ+aOIkK3vnBtFnEjksDZhc2ra6 V1MQ== Original-Received: by 10.52.69.132 with SMTP id e4mr7041008vdu.2.1349645660001; Sun, 07 Oct 2012 14:34:20 -0700 (PDT) Original-Received: by 10.58.170.40 with HTTP; Sun, 7 Oct 2012 14:34:19 -0700 (PDT) In-Reply-To: <5071E6E7.7080906@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:154207 Archived-At: 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 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=EDno Expedition, which > also anchored for a couple of days and then moved on. > > Next known visit by the Portol=E1 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=3D'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. > --=20 Tim Cross