From attila.lendvai at gmail.com Fri Sep 19 15:09:58 2008 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 19 Sep 2008 17:09:58 +0200 Subject: [local-time-devel] java is getting a new date api, we may steal ideas from there Message-ID: http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html -- attila From attila.lendvai at gmail.com Tue Sep 23 21:47:00 2008 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 23 Sep 2008 23:47:00 +0200 Subject: [local-time-devel] The Official Timezone Repository: http://www.date-time-zone.com/ Message-ID: hi! just wanted to share this link, which seems to be The Official Timezone Repository, updated every few weeks: http://www.date-time-zone.com/ they have an xml version that contains a nice structured representation of the timezone info. i've started to port cl-l10n to extract the locale info from the cldr xml repository, and my experience is absolutely positive compared to parsing the aging unix locale files. i think we should consider parsing the xml available from the above link. i don't have much time for it nowadays, but i can set up the cxml parsing part if someone wants to work on it. it parses the xml file into clos instances ready for generic dispatch based processing. -- attila From dlowe at bitmuse.com Mon Sep 29 14:41:34 2008 From: dlowe at bitmuse.com (Daniel Lowe) Date: Mon, 29 Sep 2008 10:41:34 -0400 Subject: [local-time-devel] The Official Timezone Repository: http://www.date-time-zone.com/ In-Reply-To: References: Message-ID: <48E0E91E.20209@bitmuse.com> Attila Lendvai wrote: > just wanted to share this link, which seems to be The Official > Timezone Repository, updated every few weeks: > http://www.date-time-zone.com/ > > they have an xml version that contains a nice structured > representation of the timezone info. That's great, but I don't think we can realistically use this. I'd rather not a) introduce a dependency on or include an xml parser and b) have to parse a 6.7MB file for timezone information, the majority of which a user will never use. I'm unsatisfied with the way we're handling timezones, but I think the eventual way forward is to parse the uncompiled tzdata files, which are guaranteed to be maintained and have a one-file-per-timezone structure. : Daniel : From dlowe at bitmuse.com Mon Sep 29 14:44:15 2008 From: dlowe at bitmuse.com (Daniel Lowe) Date: Mon, 29 Sep 2008 10:44:15 -0400 Subject: [local-time-devel] java is getting a new date api, we may steal ideas from there In-Reply-To: References: Message-ID: <48E0E9BF.3060906@bitmuse.com> Attila Lendvai wrote: > http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html I looked at Joda a few months ago and was impressed at the depth of their thinking on time representation. I'm not surprised it's being blessed by the Java committee. Separating inexact and exact time specifications is a great idea, and one I'm working on with local-time. : Daniel : From attila.lendvai at gmail.com Mon Sep 29 15:48:10 2008 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 29 Sep 2008 17:48:10 +0200 Subject: [local-time-devel] The Official Timezone Repository: http://www.date-time-zone.com/ In-Reply-To: <48E0E91E.20209@bitmuse.com> References: <48E0E91E.20209@bitmuse.com> Message-ID: > That's great, but I don't think we can realistically use this. I'd rather not > a) introduce a dependency on or include an xml parser > and b) have to parse a 6.7MB file for timezone information, the majority of > which a user will never use. we could leave the parsing to the lib developers using some code that is not loaded by default. the result of the parsing is then encoded in a more lisp-friendly way and added to the repository (e.g. factory-functions in one big .lisp file, read'able sexps in a one timezone per file format, etc) of course this is all superfluous complexity if the parsing code is small, fast and doesn't need any external dependencies. btw, i was wrongly suggesting that the link in my previous mail is pointing to some canonical timezone repository. the most canonical db i can find now is this: http://www.twinsun.com/tz/tz-link.htm (note: this page has an "Other time zone databases" section). probably the tzdata files are also compiled from this. -- attila