Received: by 10.90.2.16 with SMTP id 16mr1722785agb.8.1270104966958;
        Wed, 31 Mar 2010 23:56:06 -0700 (PDT)
Received: by 10.90.2.16 with SMTP id 16mr1722770agb.8.1270104966028;
        Wed, 31 Mar 2010 23:56:06 -0700 (PDT)
Return-Path: <ricky.rom...@gmail.com>
Received: from mail-yx0-f137.google.com (mail-yx0-f137.google.com [209.85.210.137])
        by gmr-mx.google.com with ESMTP id 18si709505ywh.13.2010.03.31.23.56.06;
        Wed, 31 Mar 2010 23:56:06 -0700 (PDT)
Received-SPF: pass (google.com: domain of ricky.rom...@gmail.com designates 209.85.210.137 as permitted sender) client-ip=209.85.210.137;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ricky.rom...@gmail.com designates 209.85.210.137 as permitted sender) smtp.mail=ricky.rom...@gmail.com
Received: by yxe2 with SMTP id 2so58970yxe.13
        for <timezone-js@googlegroups.com>; Wed, 31 Mar 2010 23:56:06 -0700 (PDT)
MIME-Version: 1.0
Received: by g28g2000yqh.googlegroups.com with HTTP; Wed, 31 Mar 2010 23:56:05 
	-0700 (PDT)
Date: Wed, 31 Mar 2010 23:56:05 -0700 (PDT)
In-Reply-To: <20100330210622.GA31874@x61s.reliablesolutions.de>
X-IP: 67.188.212.180
References: <4bb244b74f773_14763fdd73077afc1a2@fe2.rs.github.com.tmail> 
	<20100330210622.GA31874@x61s.reliablesolutions.de>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) 
	AppleWebKit/532.9 (KHTML, like Gecko) Chrome/5.0.307.11 Safari/532.9,gzip(gfe)
Received: by 10.101.135.11 with SMTP id m11mr19116ann.43.1270104965964; Wed, 
	31 Mar 2010 23:56:05 -0700 (PDT)
Message-ID: <00f2296f-457c-40fe-a5b4-0fc38f20c28c@g28g2000yqh.googlegroups.com>
Subject: Re: Changes to timezone-js
From: Ricky Romero <ricky.rom...@gmail.com>
To: timezone-js <timezone-js@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'm doing a bit of an evil thing.  :-P  I'm scraping timeanddate.com
for a ton of time zone changes that we can test against.  Not all of
the cases will map to the TZ database, and more recent rules will
probably not match up right, but anything from 1930 to 2000 should
make for a pretty good batch.  There are so many different time
changes that I think we would be remiss if we didn't have a generous
test suite.

I'm thinking about breaking the data into one file per TZ name, so
"America/Chicago" would be one test suite, and "Africa/Tripoli" would
be another.

This will probably take some time to grab and massage into something
we can test against, so I'll see about reporting back later this week.


Ricky

On Mar 30, 2:06=A0pm, Jan Niehusmann <j...@gondor.com> wrote:
> Hi Matthew,
>
> as you suggested to discuss this on the mailing list, I hope it's ok
> that I just answer your mail through the list.
>
> > I wish we'd talked about tests from the very beginning -- the removal o=
f the after-September hack breaks the tests for Jerusalem and Sao Paulo. We=
 should talk about how to fix this best for everybody.
>
> Unit tests are indeed very important for such a library as it's really
> easy to break some corner cases while fixing some other ones.
>
> Therefore I had a look at the JSUnit tests today. But I had to do
> some changes to make them work at all:
>
> - test.html doesn't set timezoneJS.timezone.defaultZoneFile which breaks
> =A0 all tests for non north-american time zones.
>
> - asynchronous loading of time zone data made the tests fail sometimes.
> =A0 With async:false it works reliably
>
> - Brazil changed time zone rules in 2008 (the change was announced only
> =A0 a few weeks in advance). One test case for Sao Paulo is still using
> =A0 the old rules and therefore fails with recent rule definitions.
>
> I pushed these changes to github on branch 'jsunit', so you can apply
> them easily and independently from the other changes.
>
> Making this work took some time, so I didn't finish testing and updating
> my changes to the timezone code.
>
> But I'll probably have some spare time during the next few days so can
> keep working on that.
>
> Comments on my patches are always welcome, but at the moment it's
> probably better to consider them as experimental.
>
> Jan