Re: [iola-conversion-tool] Timezone

Ole Laursen <olau@iola.dk> Fri, 23 March 2012 12:19 UTC

Return-Path: <olau@iola.dk>
X-Original-To: iola-conversion-tool@ietfa.amsl.com
Delivered-To: iola-conversion-tool@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CF321F84BD for <iola-conversion-tool@ietfa.amsl.com>; Fri, 23 Mar 2012 05:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.851
X-Spam-Level:
X-Spam-Status: No, score=-2.851 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kl604F4JwnP for <iola-conversion-tool@ietfa.amsl.com>; Fri, 23 Mar 2012 05:19:10 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 438ED21F846B for <iola-conversion-tool@ietf.org>; Fri, 23 Mar 2012 05:19:09 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so3311839vcb.31 for <iola-conversion-tool@ietf.org>; Fri, 23 Mar 2012 05:19:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=smZaF51h6I2FKaXBRAZAmPr7paOGJT6ZNMtW6bl9x2k=; b=n/KeGQy8cxlvfHyg5yB8sqGVb5BCVeFuHGiUj+VEi98S3UdqF+QhVCyW6pVotgz3Q7 Jzw0UsJZt2w2x51ED3Ctdcuf5MLGjhSrkZehc3IBwJqifuxkirEMqLJNDnQ7GCPKWL/Q x2mioZ4lLP+fxjJ5hy1y4ecRrp6wQClG3tmEf8AQntst1Yl81AKR2lxmJGelU+yYZ6Qw 4sCw1De5YHMg2+a6/ut0J0k9nxaM9m//DcQStmff5atV/PdPUPz8n8EWlwIzCgKReU96 vEV7Xp6klVRiTe3EJ+dBRhl3R9p+PRCvwEIYc1FdiSRPxT+XwfYOFdS/fe4+vDBGJAZm DAMg==
Received: by 10.220.230.74 with SMTP id jl10mr5360483vcb.32.1332505149444; Fri, 23 Mar 2012 05:19:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.71.136 with HTTP; Fri, 23 Mar 2012 05:18:49 -0700 (PDT)
In-Reply-To: <ABFE458F-513A-461D-B35F-03868423A3DF@nostrum.com>
References: <4F6B6C19.7020909@nostrum.com> <CANb2Ov+qByBaVfe=kNj-6YpmgOgNyG+UYSrmLaK6TpwWYSZK8g@mail.gmail.com> <ABFE458F-513A-461D-B35F-03868423A3DF@nostrum.com>
From: Ole Laursen <olau@iola.dk>
Date: Fri, 23 Mar 2012 13:18:49 +0100
Message-ID: <CANb2OvKYqU9-Em2VVqb1Ao80ShTikR=zxUAMcJWutKrpXnX8kw@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmijXjQpNXPcZHAiFY9Xu1chN2Q/MdfdFYRLvUrUhFsYROMDxwk1hfAEjwy4btYSzLznwDU
Cc: "iola-conversion-tool@ietf.org" <iola-conversion-tool@ietf.org>
Subject: Re: [iola-conversion-tool] Timezone
X-BeenThere: iola-conversion-tool@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the IOLA / DB Schema Conversion Tool Project <iola-conversion-tool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iola-conversion-tool>, <mailto:iola-conversion-tool-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iola-conversion-tool>
List-Post: <mailto:iola-conversion-tool@ietf.org>
List-Help: <mailto:iola-conversion-tool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iola-conversion-tool>, <mailto:iola-conversion-tool-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Mar 2012 12:19:11 -0000

2012/3/22 Adam Roach <adam@nostrum.com>om>:
> From an ical perspective, the time zone block should encode the DST rules for the locale under a single label. The old database only gave us an integer offset, so the output we presently generate is very primitive (and slightly wrong). It sounds like the new DB is much more intelligent about this kind of thing. Hopefully, my code refactor of the agenda code on Saturday will result in doing this correctly.

Ah, that sounds even better. Yes, we store a name, it's supposed to be
a name from the standard time zone database, I think. If you discover
some brokenness regarding that, it's probably better to fix the
database than continue with a hack.


Ole