New home for time zone stuff by 2012?

Mark Peek mark at peek.org
Mon Aug 31 17:03:30 UTC 2009


I believe ado was requesting offers and comments for a new home for the time 
zone stuff. You and others may disagree with the UC idea while others may 
agree with it  That is what an open discussion is all about.

Yes, the current mechanism in the right hands (individual or consortium) would 
continue to work. As I stated, I would prefer a single source of tzdata and 
not see this splintered into competing "standards". It would be good to hear 
what ado thinks about the discussion and direction of this thread.

BTW, your name categorization was needless additional commentary. Please stay 
with the discussion thread without name innuendo.

Mark

On 8/31/09 9:30 AM, Dafydd Rhys-Jones wrote:
> I disagree completely. Although the Unicode Consortium is a great place, I don't think the time zone category fits in to any consortium, or organization outside of what it is now. My beliefs fall in line with Jaakko, Eliot, et al. 
> 
> What we have right now works, would work in the future, and in my opinion, should continue to work as such, just in the hands of someone who Ado selects to continue these updates.
> 
> If the Consortium feels that they are the ones to take on this project, then they may want to look at creating their own open source system, running, and updating it as they lay claim to doing, and see whose gets (or stays) adopted. This means some sort of a split, which would allow vendors to decide who is better to go with for time zone information and reliable updates.
> 
> If anything, I would imagine an educational institute being qualified to oversee this project.
> 
> I think it's a "Mark" thing. There have been a few Mark's who like the Unicode Consortium idea. 0]
> 
> Cheers,
> Dafydd
>  
>  
>  
> -----Original Message-----
> From: Mark Peek [mailto:mark at peek.org] 
> Sent: Monday, August 31, 2009 8:14 AM
> To: tz at lecserver.nci.nih.g
> Subject: Re: New home for time zone stuff by 2012?
> 
> When ado sent out the first email on this thread, my first thought was that 
> the Unicode Consortium would be a great place to maintain the timezone data. 
> Throughout the resulting discussion I am still a "+1" for it to be maintained 
> there. I believe Mark Davis has commented on different levels of release 
> flexibility within the Unicode Consortium and I think the dialog has indicated 
> that a fast and flexible release time line is what the users of tzdata are 
> wanting. I am sure the Unicode Consortium would want to ensure the continued 
> success, continuity and single source of tzdata if it was agreed for them to 
> take this on.
> 
> Still a +1 for Unicode Consortium.
> 
> Mark
> 
> On 8/30/09 7:00 PM, Robert Masters wrote:
>> Mark,
>>  
>> I do understand the there are a number of descriptive (vs prescriptive) 
>> standardization efforts, however very few of them are intended to 
>> maintain a constantly changing reality. This is the destinction I was 
>> trying to draw. The conventional standardization process either creates 
>> a model of a reality, and then enforces that model (with occasional 
>> refinements or modifications), or creates a new prescriptive model that 
>> is likewise updated on a relatively infrequent basis.
>>  
>> In both cases, the intent is for the operational reality to follow the 
>> standard (even if the standard is originally derived from that 
>> operational reality).
>>  
>> The TZ database is a somewhat different kettle of fish, in that it is 
>> more a process of documenting a constantly changing reality. This 
>> process is orthoginal to the conventional standardization process - be 
>> it descriptive (Unicode Locales) or prescriptive (802.11i) in origin.
>>  
>> In the case of live documentation, you are constantly attempting to keep 
>> up with a changing reality - this requires a greater agility and 
>> responsiveness than your typical formal standard. Conversely, and to use 
>> your example of the Unicode Locales project, once the standard is 
>> documented, it is unlikely that the (for example) date format custom for 
>> a particular region will change in the space of a few days. This is the 
>> sort of rapid change that is commonplace for the TZ database project.
>>  
>> Based on this, I feel that placing the TZ database project under the 
>> control of a traditional standards body with not be appropriate, due to 
>> the very different style of maintenance and thinking required.
>>  
>>
>> Regards
>>
>>  
>>
>> Rob Masters
>>
>> *Unix Systems Administrator*
>>
>>  
>>
>> Bunnings Group Limited
>>
>> 126 Pilbara Street, Welshpool WA 6106
>>
>> Locked Bag 20, Welshpool WA 6986
>>
>> Phone: (08) 9365-1507
>>
>> E-mail : rmasters at bunnings.com.au <mailto:rmasters at bunnings.com.au>
>>
>> Website: www.bunnings.com.au <http://www.bunnings.com.au>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* mark.edward.davis at gmail.com [mailto:mark.edward.davis at gmail.com] 
>> *On Behalf Of *mark at macchiato.com
>> *Sent:* Saturday, 29 August 2009 7:38 AM
>> *To:* tz at lecserver.nci.nih.gov
>> *Cc:* tz at lecserver.nci.nih.gov
>> *Subject:* Re: New home for time zone stuff by 2012?
>>
>> There may be some misunderstanding here. While there are some 
>> standardization efforts that are perscriptive, many standardization 
>> efforts are targeted at "reflecting reality as closely as possible". The 
>> Unicode Locales project, for example, aims at getting translations, date 
>> formats, time formats, etc. on the basis of customary usage.
>>
>> Mark
>>
>>
>> On Thu, Aug 27, 2009 at 16:48, Robert Masters <RMasters at bunnings.com.au 
>> <mailto:RMasters at bunnings.com.au>> wrote:
>>
>>
>>     Thank-you Russ!
>>
>>     That is exactly the sort of response I was hoping for - why NOT to use
>>     my suggestion.
>>
>>     Further, your suggestion has a number of very good points to support it.
>>
>>     Eyrie.org has been around for a long time by net standards (over 10
>>     years now), and has always been well maintained and resourced. They
>>     provide the same benefits that Sourceforge offer, with none of the
>>     problems that the site currently suffers from. It is independent of a
>>     formal body, providing a separation from bureaucratic controls, and is
>>     likewise separated from an individual's place of employment.
>>
>>     I do not think that moving the project under the umbrella of a standards
>>     or similar organistation will be of particular benefit, as the point of
>>     the project is to reflect reality as closely as possible, not to try to
>>     enforce a standard on reality. In many ways it requires the exact
>>     opposite of a standards body.
>>
>>     Regards
>>
>>     Rob Masters
>>     Unix Systems Administrator
>>
>>     Bunnings Group Limited
>>     126 Pilbara Street, Welshpool WA 6106
>>     Locked Bag 20, Welshpool WA 6986
>>     Phone: (08) 9365-1507
>>     E-mail : rmasters at bunnings.com.au <mailto:rmasters at bunnings.com.au>
>>     Website: www.bunnings.com.au <http://www.bunnings.com.au>
>>
>>
>>     -----Original Message-----
>>     From: Russ Allbery [mailto:rra at stanford.edu <mailto:rra at stanford.edu>]
>>     Sent: Friday, 28 August 2009 2:55 AM
>>     To: tz at lecserver.nci.nih.gov <mailto:tz at lecserver.nci.nih.gov>
>>     Subject: Re: New home for time zone stuff by 2012?
>>
>>     "Olson, Arthur David (NIH/NCI) [E]" <olsona at dc37a.nci.nih.gov
>>     <mailto:olsona at dc37a.nci.nih.gov>> writes:
>>
>>      > I'll be eligible to start drawing a pension in mid-2012. Since I'm
>>      > accustomed to slow-moving Quaker process, that makes it time to get
>>      > serious about finding a new home for time zone stuff.
>>
>>      > There are several pieces of the puzzle (some of which haven't seen
>>      > much work of late):
>>
>>      >       Data maintenance
>>      >       Data distribution
>>      >       Code maintenance
>>      >       Code distribution
>>      >       Mailing list maintenance
>>      >       Mailing list hosting
>>      >       Standards work (for example, tweaking POSIX TZ environment
>>     variables so Godthab can be represented)
>>      >       Code enhancement (for example, year zero work and Julian
>>     calendar
>>      > work)
>>
>>     Since it's been explicitly mentioned as a suggestion, I guess I'll be
>>     one to stand up and say that I'd really hate to see this work move to
>>     Sourceforge.  The Sourceforge site is riddled with advertising in ways
>>     that have gotten increasingly obnoxious over the years, it's slow, it's
>>     often buggy, and the mailing lists that it hosts have historically also
>>     mangled outgoing messages with even more advertising.
>>
>>     In the name of not complaining about something without offering an
>>     alternative:
>>
>>     Moving from hosting based on the current maintainer to hosting based on
>>     another individual may not be the best approach, and I certainly
>>     understand if people would prefer something more distributed that makes
>>     it easier to have continuity of access.  However, I'm willing to host
>>     the infrastructure for continuing to distribute and discuss the timezone
>>     database personally, particularly as an alternative to seeing it move to
>>     Sourceforge.
>>
>>     eyrie.org <http://eyrie.org> is my personal domain, independent of
>>     any employment of mine,
>>     and can offer:
>>
>>     * Mailing list hosting (via Mailman)
>>     * Mailing list maintenance (I'm willing to review the moderation queue)
>>     * Data distribution via archives.eyrie.org
>>     <http://archives.eyrie.org> / ftp.eyrie.org <http://ftp.eyrie.org>
>>     * Code distribution via archives.eyrie.org
>>     <http://archives.eyrie.org> / ftp.eyrie.org <http://ftp.eyrie.org>
>>
>>     If the number of downloads of the source and data is in excess of a few
>>     GiB a day of network traffic averaged over a month, hosting the
>>     distribution is a bit trickier, but I think it's unlikely that would be
>>     the case.  That's over 10,000 downloads of the tarball a day, and I
>>     suspect nearly all users get it via distributions or other sources.
>>
>>     If whoever is doing the maintenance would like to use a revision control
>>     system, I'm happy to host the repository with the caveat that I would
>>     like to keep the number of people with access small and restricted to
>>     people whose identities I can be reasonably assured about, since I don't
>>     have the distributed hosting facilities of a Sourceforge or the like.
>>     If the intention is to move to a more open commit model, it would
>>     probably be better to explore an option like GitHub, Savannah, or a
>>     similar project hosting provider.  If the project would stay with a
>>     single committer who just needs a place to upload things, I can
>>     certainly provide that.
>>
>>     --
>>     Russ Allbery (rra at stanford.edu <mailto:rra at stanford.edu>)
>>     <http://www.eyrie.org/~eagle/ <http://www.eyrie.org/%7Eeagle/>>
>>
>>
>>     ************************************************************************
>>     Bunnings Legal Disclaimer:
>>
>>     1)     This email is confidential and may contain legally privileged
>>     information.  If you are not the intended recipient, you must not
>>     disclose or use the information contained in it.  If you have received
>>     this email in error, please notify us immediately by return email and
>>     delete the document.
>>
>>     2)     All emails sent to and sent from Bunnings Group Limited.
>>     are scanned for content.  Any material deemed to contain inappropriate
>>     subject matter will be reported to the email administrator of all
>>     parties concerned.
>>     ************************************************************************
>>
>>
>>
>> ************************************************************************
>> Bunnings Legal Disclaimer:
>>
>> 1) This email is confidential and may contain legally privileged
>> information. If you are not the intended recipient, you must not
>> disclose or use the information contained in it. If you have received
>> this email in error, please notify us immediately by return email and
>> delete the document.
>>
>> 2) All emails sent to and sent from Bunnings Group Limited.
>> are scanned for content. Any material deemed to contain inappropriate
>> subject matter will be reported to the email administrator of all
>> parties concerned.
>> ************************************************************************
> 
> 




More information about the tz mailing list