From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: The Emacs Calculator and calendar Date: Sun, 07 Oct 2012 13:32:39 -0700 Organization: UCLA Computer Science Department Message-ID: <5071E6E7.7080906@cs.ucla.edu> References: <87y5jk3f7d.fsf@gmail.com> <87626md8aj.fsf@Rainer.invalid> <83vcem6592.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1349641967 15382 80.91.229.3 (7 Oct 2012 20:32:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Oct 2012 20:32:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 07 22:32:53 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 1TKxWt-0000zv-UK for ged-emacs-devel@m.gmane.org; Sun, 07 Oct 2012 22:32:52 +0200 Original-Received: from localhost ([::1]:48083 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKxWn-0002sT-UY for ged-emacs-devel@m.gmane.org; Sun, 07 Oct 2012 16:32:45 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKxWk-0002sL-B8 for emacs-devel@gnu.org; Sun, 07 Oct 2012 16:32:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TKxWj-0007VP-1U for emacs-devel@gnu.org; Sun, 07 Oct 2012 16:32:42 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:43710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKxWi-0007VD-PJ for emacs-devel@gnu.org; Sun, 07 Oct 2012 16:32:40 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 5162039E800D; Sun, 7 Oct 2012 13:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l65guoVJiaIU; Sun, 7 Oct 2012 13:32:38 -0700 (PDT) Original-Received: from [192.168.1.3] (pool-108-23-119-2.lsanca.fios.verizon.net [108.23.119.2]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id C231739E8007; Sun, 7 Oct 2012 13:32:38 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 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:154205 Archived-At: 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=C3=ADno Expedition, which also anchored for a couple of days and then moved on. Next known visit by the Portol=C3=A1 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.