Please remove -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: Tuesday, August 25, 2009 8:21 AM To: 'tz@elsie.nci.nih.gov' Subject: RE: New home for time zone stuff by 2012? I've removed you from the list; thanks for your participation. --ado -----Original Message----- From: Phillip Guerra [mailto:Phillip.Guerra@nkch.org] Sent: Tuesday, August 25, 2009 9:18 To: tz@lecserver.nci.nih.gov Subject: RE: New home for time zone stuff by 2012? My present position is being eliminated. Please remove me from the mailing list, Thanks for all of your hard work, and I wish you the best. -----Original Message----- From: Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Sent: Sunday, August 23, 2009 1:51 PM To: tz@elsie.nci.nih.gov Subject: New home for time zone stuff by 2012? 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) There are different types of landing place: Governmental organizations Non-governmental organizations Commercial entities Volunteers Everything could be moved under one new roof or different pieces might go different places. While I'm happy to continue time zone work in the future, I also understand that it may be best for others to do the work. Anyone? Bueller? --ado Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s), and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender of this email, and destroy all copies of the original message.

I was about to suggest this, but am concerned about whether having the TZ project under the UC umbrella would really allow it to "continue basically as it does now." Other projects under UC such as CLDR have lengthy input/review/release cycles, but the TZ data has to be able to be turned around quickly due to the unpredictability of time changes in some countries (Egypt is still fresh in my mind). -- Larry Gilbert <lgilbert@digium.com> Digium | Switchvox On Thu, 2009-08-27 at 10:48 -0700, Mark Davis ⌛ wrote:

The officers of the Unicode Consortium (http://unicode.org) have discussed this issue, and are interested in exploring hosting the TZ efforts. Aside from the Unicode projects, we currently also support other independent efforts (http://www.unicode.org/iso15924/, http://www.unicode.org/udhr/). Hosting the TZ project would provide for mailing list hosting, code distribution, source code repository (SVN) if desired, etc., web pages, etc. -- presuming that the functioning of the TZ group would continue basically as it does now.

-----Original Message----- From: akuster [mailto:akuster@mvista.com] Sent: Thursday, August 27, 2009 11:33 AM To: tz@lecserver.nci.nih.gov Cc: tz@lecserver.nci.nih.gov Subject: Re: Unicode Consortium (Re: New home for time zone stuff by 2012?) Larry Gilbert wrote:

I was about to suggest this, but am concerned about whether having the TZ project under the UC umbrella would really allow it to "continue basically as it does now." Other projects under UC such as CLDR have lengthy input/review/release cycles, but the TZ data has to be able to be turned around quickly due to the unpredictability of time changes in some countries (Egypt is still fresh in my mind).

I have the same concern. ado has been awesome in addressing time critical changes. - armin I agree completely with this statement. There have been occurrences in the past where a government has changed its mind about setting DST <1 month before the time change event was supposed to occur. Dafydd Rhys-Jones

The Unicode consortium projects have very different processes and release schedules. - The Unicode Standard process is the heaviest; it uses larger quarterly physical meetings, plus smaller monthly one-day meetings, and has releases about 1 to 1.5 years. - Script updates use email communication only, and may be updated in weeks. - CLDR uses weekly phone meetings and email; a major release of CLDR can take 9-12 months, but a dot-dot update of CLDR only needs days. - A change in the UDHR can be done overnight. So it all depends on the process the TZ group wants to use. (BTW, in Google we are well aware of the need for speed; getting our products updated around the globe with new TZ data with notice of only a week or two is extremely painful!) Mark On Thu, Aug 27, 2009 at 11:22, Larry Gilbert <lgilbert@digium.com> wrote:

I was about to suggest this, but am concerned about whether having the TZ project under the UC umbrella would really allow it to "continue basically as it does now." Other projects under UC such as CLDR have lengthy input/review/release cycles, but the TZ data has to be able to be turned around quickly due to the unpredictability of time changes in some countries (Egypt is still fresh in my mind).

-- Larry Gilbert <lgilbert@digium.com> Digium | Switchvox

On Thu, 2009-08-27 at 10:48 -0700, Mark Davis ⌛ wrote:

...

The officers of the Unicode Consortium (http://unicode.org) have discussed this issue, and are interested in exploring hosting the TZ efforts. Aside from the Unicode projects, we currently also support other independent efforts (http://www.unicode.org/iso15924/, http://www.unicode.org/udhr/). Hosting the TZ project would provide for mailing list hosting, code distribution, source code repository (SVN) if desired, etc., web pages, etc. -- presuming that the functioning of the TZ group would continue basically as it does now.

To put it in perspective, the CLDR project has thousands of pieces of data in hundreds of languages. The scope of the CLDR project is vastly bigger than TZ. That being said, I'm confident that if unicode were to take over tz, then you could still get VERY quick turnaround when you needed to. I would think this would be a good move for both TZ and Unicode. Regards, John C. Emmons Unicode CLDR Project vice-chair Globalization Architect IBM Software Group, Austin TX From: Jonathan Leffler <jonathan.leffler@gmail.com> To: tz@lecserver.nci.nih.gov Cc: tz@lecserver.nci.nih.gov Date: 08/27/2009 02:11 PM Subject: Re: New home for time zone stuff by 2012? On Thu, Aug 27, 2009 at 10:48 AM, Mark Davis ⌛ <mark@macchiato.com> wrote: The officers of the Unicode Consortium (http://unicode.org) have discussed this issue, and are interested in exploring hosting the TZ efforts. Aside from the Unicode projects, we currently also support other independent efforts (http://www.unicode.org/iso15924/, http://www.unicode.org/udhr/). Hosting the TZ project would provide for mailing list hosting, code distribution, source code repository (SVN) if desired, etc., web pages, etc. -- presuming that the functioning of the TZ group would continue basically as it does now. Unicode also host the CLDR - Common Locale Data Repository. Although not the same as the TZ data, there is at least some commonality in theme. If there is interest in something along these lines, we can discuss more specifics of what this would look like and then pass a proposal by our board of directors. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

Speaking to "I don't think I'd want Unicode specifying any of:" We'd be hosting the TZ group; the process the group uses and its output would be up to the group. (The only thing we'd need is for the group to provide a description of whatever process *is* being followed.) Mark And by the way, even for Unicode, the consortium is not in the business of specifying APIs or binary file formats; I don't know where that perception arose. On Thu, Aug 27, 2009 at 14:33, Bill Seymour <stdbill.h@pobox.com> wrote:

On Thu, Aug 27, 2009 at 2:58 PM, John Emmons<emmo@us.ibm.com> wrote:

...

I would think this would be a good move for both TZ and Unicode.

Why? Beyond getting localized time zone names in the CLDR, where's the expertise?

If this is just an offer for hosting an HTTP and FTP site, then cool; but I don't think I'd want Unicode specifying any of: - source file formats. - binary file formats. - APIs.

--Bill Seymour

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@bunnings.com.au Website: www.bunnings.com.au -----Original Message----- From: Russ Allbery [mailto:rra@stanford.edu] Sent: Friday, 28 August 2009 2:55 AM To: tz@lecserver.nci.nih.gov Subject: Re: New home for time zone stuff by 2012? "Olson, Arthur David (NIH/NCI) [E]" <olsona@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 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 / ftp.eyrie.org * Code distribution via archives.eyrie.org / 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@stanford.edu) <http://www.eyrie.org/~eagle/> ************************************************************************ 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. ************************************************************************

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@bunnings.com.au <mailto:rmasters@bunnings.com.au> Website: www.bunnings.com.au ________________________________ From: mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] On Behalf Of mark@macchiato.com Sent: Saturday, 29 August 2009 7:38 AM To: tz@lecserver.nci.nih.gov Cc: tz@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@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@bunnings.com.au Website: www.bunnings.com.au -----Original Message----- From: Russ Allbery [mailto:rra@stanford.edu] Sent: Friday, 28 August 2009 2:55 AM To: tz@lecserver.nci.nih.gov Subject: Re: New home for time zone stuff by 2012? "Olson, Arthur David (NIH/NCI) [E]" <olsona@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 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 / ftp.eyrie.org * Code distribution via archives.eyrie.org / 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@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. ************************************************************************

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@bunnings.com.au <mailto:rmasters@bunnings.com.au>

Website: www.bunnings.com.au <http://www.bunnings.com.au>

------------------------------------------------------------------------ *From:* mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] *On Behalf Of *mark@macchiato.com *Sent:* Saturday, 29 August 2009 7:38 AM *To:* tz@lecserver.nci.nih.gov *Cc:* tz@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@bunnings.com.au <mailto:RMasters@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@bunnings.com.au <mailto:rmasters@bunnings.com.au> Website: www.bunnings.com.au <http://www.bunnings.com.au>

-----Original Message----- From: Russ Allbery [mailto:rra@stanford.edu <mailto:rra@stanford.edu>] Sent: Friday, 28 August 2009 2:55 AM To: tz@lecserver.nci.nih.gov <mailto:tz@lecserver.nci.nih.gov> Subject: Re: New home for time zone stuff by 2012?

"Olson, Arthur David (NIH/NCI) [E]" <olsona@dc37a.nci.nih.gov <mailto:olsona@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@stanford.edu <mailto:rra@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. ************************************************************************

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@peek.org] Sent: Monday, August 31, 2009 8:14 AM To: tz@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@bunnings.com.au <mailto:rmasters@bunnings.com.au>

Website: www.bunnings.com.au <http://www.bunnings.com.au>

------------------------------------------------------------------------ *From:* mark.edward.davis@gmail.com [mailto:mark.edward.davis@gmail.com] *On Behalf Of *mark@macchiato.com *Sent:* Saturday, 29 August 2009 7:38 AM *To:* tz@lecserver.nci.nih.gov *Cc:* tz@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@bunnings.com.au <mailto:RMasters@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@bunnings.com.au <mailto:rmasters@bunnings.com.au> Website: www.bunnings.com.au <http://www.bunnings.com.au>

-----Original Message----- From: Russ Allbery [mailto:rra@stanford.edu <mailto:rra@stanford.edu>] Sent: Friday, 28 August 2009 2:55 AM To: tz@lecserver.nci.nih.gov <mailto:tz@lecserver.nci.nih.gov> Subject: Re: New home for time zone stuff by 2012?

"Olson, Arthur David (NIH/NCI) [E]" <olsona@dc37a.nci.nih.gov <mailto:olsona@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@stanford.edu <mailto:rra@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. ************************************************************************

-On [20090831 17:14], Mark Peek (mark@peek.org) wrote:

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.

I can only add my +1 for hosting under the Unicode umbrella. As a individual participant and contributor in both Unicode and CLDR discussions and matters I can attest that these two projects behave very differently. A project like the timezone database could easily continue as it is now, despite being hosted there. As long as the importance of a quick turn around time and release management is stressed, I foresee no problems. If needed, I am willing to help out with this process as well as documenting it, whatever it may be. :) -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Think carefully of what you ask for, because you just may get it...

-On [20090831 18:45], akuster (akuster@mvista.com) wrote:

Just for clarification, the unicode offer is referring to the "where" for the time zone? Hosting only, not the "Who" i.e person/group maintaining the code and doing bug fixes.

Mark has made it clear from the get go that there are projects hosted by the Unicode Consortium that have nothing to do with the consortium at all. They only provide the hosting and do not interfere in the daily matters. Mark, if I misunderstood, please correct me of course. -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Who watches the watchers?

It might be best to separate the hosting issues for the tz database from the governance issues. My vote is for hosting the tz data on a site that has a higher profile in the standards world. To me, the Unicode site would be an excellent candidate. There are various reasons for wanting a higher profile url such as: It lends credibility to the data. In the past, when I have pointed people to the twinsun site, I've had to convince them that this is a reputable site and that the data can be trusted. I think a higher profile hosting site would be desirable in overcoming the skepticism with trusting this data. For those of us who have been associate with the tz data for a long time, this may be hard to understand but for those new to it, it takes a leap of faith. Personal sites or sites associated with a specific company are not desirable. Too many companies are dependent upon this data. A personal site could go away overnight if the person got hit by a bus while crossing the street. On the other hand, a corporate site raises competitive concerns. What if my competitor is controlling that data that I depend upon? Governments may be more willing to participate directly if the tz workgroup is seen as a more formal standards organization as determined by the hosting site. So, IBM would like to see the hosting done by a site with a higher profile in the open standards world. As stated above, the Unicode site is a good option, especially since they have offered to host it and they are a high profile site that hosts multiple different important standards. Clearly, someone will have to make sure that the new site has the data storage, security, and server capacity to handle the data and traffic volumes for the site. As for governance. The governing body of the tz data would determine (as they do today) the processes for updating the data and for updating the data structure. There isn't any reason that this would have to change just because the hosting organization has changed. Mark Davis said that all that the Unicode consortium would want is a clearly defined process for how updating is handled. It doesn't have to be process-heavy, just documented. That's not a bad requirement. Of course it might not be a bad idea to start thinking about how this tz database could be taken to a new level. Here are some other thoughts: It would be nice to have a formal name for this tz group. The tz database has always sounded a bit informal to me. It doesn't sound like a name and so this group doesn't seem to have a name. If it were a formal standard, maybe governments would be more willing to submit updates directly to tz. Maybe work with the governments that make regular changes such as Egypt or Brazil to establish a formal method of notification. Maybe create a tool or a standard XML format or some other more formal but reasonably easy way to submit tz changes. The rather informal approach to handling updates has worked remarkably well up to now but this group might benefit from a little more formal structure as we get ready for Mr. Olson to leave in a few years. "Formal" can still be lightweight. It would be nice if the tz mailing list was posted in a news group format or forum where different threads of discussion could be tracked separately. Since this approach to tz data has worked very well for many years, it would be unproductive to invent some new organization to do this same work. A better approach is to take this up a notch and make this into a slightly more formally recognized organization. Susan J Williams Globalization Leadership Team, IBM

Dave Rolsky <autarch@urth.org> writes:

On Mon, 31 Aug 2009, Sue Williams wrote:

...

It would be nice if the tz mailing list was posted in a news group format or forum where different threads of discussion could be tracked separately.

And also was archived by things like gmane and other convenient-to-search-and-browse places.

It has been archived by Gmane since mid-2004: http://dir.gmane.org/gmane.comp.time.tz Regards, Daniel

Robeert Elz said:

...

I know it isn't actually urgent just yet (given we apparently still have another 2 years with ado managing things), but despite all the discussion, and noise, we have still have absolutely zero volunteers for someone to be the one who will take over from ado when he eventually decides to step down. Don't be shy, feel free to suggest yourself for the position...

I'm available. Characteristics - (1) I turn 50 on 5 Nov 2009 so I guess I can squeak in on the age requirement. (2) I'm married and have two teenage kids so I can take some abuse; but I'm more used to being ignored than ignoring - I'll have to work on that. (3) I'm on the net at least a few hours every day Ommissions - (1) I have some c experience (coding professionally and personally since 1978), have read most of the tzcode archive and written some of my own functions to use tzdata. (2) I think there are enough download areas available that we wouldn't need a company sponsorship. I'd like to see multiple spots, like sourceforge and savannah for example (these are just examples, the real locations would be determined later). If it is corporately owned, I'd need to get a few assurances. Positives - (1) Of all the volunteers so far, I am undoubtedly the best qualified (unfortunately, the same logic dictates I am undoubtedly the least qualified but I won't mention that). The list of positives will need to be revisited once the applicants come pouring in. Other - The original email listed a few additional items: Data maintenance - this would be the timezone data, I can write the rules as needed. Data distribution - this would be the download server, as I said above I'd like to see a couple of public areas and some volunteer mirrors Code maintenance - I would set this up under the version control system available at the server hosting the files Code distribution - cvs and subversion would allow code to be fetched, as well as the tarfile typically provided for download Mailing list maintenance - have run majordomo and postman mailing list servers before, would likely use the home of the repository if it provided such a thing Mailing list hosting - same as maintenance above, most services like sourceforge and savannah do provide some mailing list capability Standards work (for example, tweaking POSIX TZ environment variables so Godthab can be represented) - this would need to be group work, not just me Code enhancement (for example, year zero work and Julian calendar work)- I can work on this, but as above would like group input. And wrt to the ps from Mr. Elz regarding umbrella organisations, I am in complete agreement. Thanks, =Billy Bennett -----Original Message----- From: Robert Elz [mailto:kre@munnari.OZ.AU] Sent: Thursday, September 03, 2009 1:37 PM To: tz@lecserver.nci.nih.gov Subject: Re: New home for time zone stuff by 2012? I know it isn't actually urgent just yet (given we apparently still have another 2 years with ado managing things), but despite all the discussion, and noise, we have still have absolutely zero volunteers for someone to be the one who will take over from ado when he eventually decides to step down. Don't be shy, feel free to suggest yourself for the position... As I see it, the characteristics that we're looking for are ... 1) someone likely to be able to continue in the position for 10 years or so (beyond 2012) at least - so that probably puts an upper age limit of around 50 or so (today) unless you're planning on continuing to do this after retirement 2) someone patient, and not flustered - and who can handle (some) abuse without running away or responding - that is, with the ability to calmly listen to what people say, and then ignore most of it, extracting just the important points. 3) someone who uses the net most of the time, and typically has it available 365 days a year (366 in leap years) - so that urgent changes can get made without too much delay (the occasional day off is OK, and we can arrange a deputy for vacations, but you cannot be so busy that you have no time for processing anything.) Note two things I have deliberately omitted from that list - you don't really need to know much about timezones, of the tz library functions, or C coding, or ... there are plenty of people who can, and will, supply the initial information, and then review that provided by others. Knowledge can't hurt, but isn't essential. And second, no mention of network connectivity, server availability to make the distribution available, or anything like that - finding the person is the hard part, once that is done, if it is needed (or becomes needed later) we will find the server support needed for the mailing list, data distribution, etc, that stuff is all easy. If anyone has anything else that should be added to the job description, feel free... kre ps: on umbrella organisations (which we don't really need, and certainly not right now) one issue to take notice of is ownership of the data (the collection, rather than individual facts). I know the IETF would want to blast ISOC copyright notices on everything (access would still be free, but everything they do gets copyrighted by them). I have no idea what the unicode consortium's position would be, but I wouldn't be surprised to see something similar. Currently the data files are all copyright free, licence free, just available - I'd personally prefer to keep it that way.

Hi, Someone may try to formalize the laws and document the process, but a dictator must not be bound to them or he becomes a slave. Regards, Jaakko -- Foreca Ltd Jaakko.Hyvatti@foreca.com Tammasaarenkatu 5, FI-00180 Helsinki, Finland http://www.foreca.com