From rick@unicode.org Tue Nov 6 18:58:07 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 06 Nov 2007 19:01:33 -0600 (CST) Received: from izanami (c-71-202-247-55.hsd1.ca.comcast.net [71.202.247.55]) by unicode.org (8.12.11/8.12.11) with SMTP id lA70vxnL025875; Tue, 6 Nov 2007 18:57:59 -0600 Message-Id: <200711070057.lA70vxnL025875@unicode.org> To: unicode@unicode.org Subject: New Public Review Issue: #116 Proposed Update UTS #35 LDML Date: Tue, 6 Nov 2007 16:58:02 -0800 From: Rick McGowan received: by Apple.Mailer (2.95.2) X-archive-position: 275 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: rick@unicode.org Precedence: bulk X-list: cldr-users The Unicode CLDR committee is planning to release a minor version, 1.5.1, by the end of November. There are a few changes in the specificiation associated with this change. The proposed update specification is found at: http://unicode.org/draft/reports/tr35/tr35.html Notable changes include: * Added C10. Likely Subtags for locale IDs or language tags. * Added extensive clarifications in Appendix J: Time Zone Display Names Additional changes may go in before release. Please submit any feedback via the Unicode CLDR bug form: http://www.unicode.org/cldr/bugs/locale-bugs Regards, Rick McGowan Unicode, Inc. From mark.edward.davis@gmail.com Tue Nov 6 20:34:06 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 06 Nov 2007 20:34:06 -0600 (CST) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by unicode.org (8.12.11/8.12.11) with ESMTP id lA72Y2CV024780 for ; Tue, 6 Nov 2007 20:34:06 -0600 Received: by rv-out-0910.google.com with SMTP id k15so2069732rvb for ; Tue, 06 Nov 2007 18:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=+L7rgbDIC2yo2fhEBgDcfNisG8ax7yx1y0QS17Hp9qA=; b=V3zcftxkDtuqtKZJbLAc6NF7cF+HLv9TdZJT7ks5gaUlWLb+1BriFHw4JcwXDq96ibBuuNOlGKv6JXGfYKdcH7UmW2XCon2AD4oTuaRAaMpLGymGsGXTOr8Ia8xk9Y0A1bUGAeRJy073L46WbB+oU4yilFtIHwNCl88NI/A4mLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=Z0pk6UiL91xv8f4ruCwNbI8H8IOqTXb/es/7VIPNN5BTkxX8BNEWGIjaYNjqeOWt6liin3mOoE6Jelmw4x1RFVxkbhopw7J1J5wUXKN6eRliT3TEBuMzzFoSRr2Bca2ICVnXofnvOdNg7M+YjFWqZm8S9WTtqOpNUhf4wqu2w44= Received: by 10.114.161.11 with SMTP id j11mr327603wae.1194402838802; Tue, 06 Nov 2007 18:33:58 -0800 (PST) Received: by 10.114.192.9 with HTTP; Tue, 6 Nov 2007 18:33:58 -0800 (PST) Message-ID: <30b660a20711061833h73dd0b00u79045d929fa038f2@mail.gmail.com> Date: Tue, 6 Nov 2007 18:33:58 -0800 From: "Mark Davis" To: "CLDR list" , cldr-users@unicode.org Subject: How to help get your language supported in software and on the web MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_33856_19409091.1194402838791" X-Google-Sender-Auth: 695f213f24925e23 X-archive-position: 276 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: mark.davis@icu-project.org Precedence: bulk X-list: cldr-users ------=_Part_33856_19409091.1194402838791 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline We've been asked to produce a page describing how linguists and others can help to get languages supported in software and on the web. There is a (very rough) draft at: http://docs.google.com/Doc?id=dfqr8rd5_25f4gmg8 Feedback is welcome. -- Mark ------=_Part_33856_19409091.1194402838791 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline We've been asked to produce a page describing how linguists and others can help to get languages supported in software and on the web. There is a (very rough) draft at:

http://docs.google.com/Doc?id=dfqr8rd5_25f4gmg8

Feedback is welcome.
--
Mark ------=_Part_33856_19409091.1194402838791-- From rick@unicode.org Fri Nov 16 12:00:11 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 16 Nov 2007 12:04:22 -0600 (CST) Received: from izanami (c-71-202-247-55.hsd1.ca.comcast.net [71.202.247.55]) by unicode.org (8.12.11/8.12.11) with SMTP id lAGI03Gw011953; Fri, 16 Nov 2007 12:00:06 -0600 Message-Id: <200711161800.lAGI03Gw011953@unicode.org> To: unicode@unicode.org Subject: Update to Public Review Issue #103 (Proposed Update UAX #29) Date: Fri, 16 Nov 2007 10:00:03 -0800 From: Rick McGowan received: by Apple.Mailer (2.95.2) X-archive-position: 277 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: rick@unicode.org Precedence: bulk X-list: cldr-users Public Review Issue #103: Proposed Update to UAX #29 http://www.unicode.org/reports/tr29/tr29-12.html This proposed update has been updated to draft 3. Note that this new draft reflects a change of title to "Unicode Text Segmentation" which will be applied in Unicode 5.1.0. Specific changes in this draft include the following: * Added SContinue (sentence-continue) to improve sentence segmentation * Added MidNumLet to improve word segmentation, by allowing certain characters to "bridge" both numbers and alphabetic words. * Added informative note and open issue on the use of space in numbers. * Made changes to property values for Word/Sentence break. For many of these, there are open issues in the document for which UTC would appreciate feedback. (See the Modifications section of the document for details.) The period for public review closes on January 28, 2008. If you have comments for official UTC consideration, please post them by submitting your comments through our feedback & reporting page: http://www.unicode.org/reporting.html If you wish to discuss issues on the Unicode mail list, then please use the following link to subscribe (if necessary). Please be aware that discussion comments on the Unicode mail list are not automatically recorded as input to the UTC. You must use the reporting link above to generate comments for UTC consideration. http://www.unicode.org/consortium/distlist.html Regards, Rick McGowan Unicode, Inc. From rick@unicode.org Fri Nov 16 17:13:51 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 16 Nov 2007 17:19:39 -0600 (CST) Received: from izanami (c-71-202-247-55.hsd1.ca.comcast.net [71.202.247.55]) by unicode.org (8.12.11/8.12.11) with SMTP id lAGNDdKT011455; Fri, 16 Nov 2007 17:13:40 -0600 Message-Id: <200711162313.lAGNDdKT011455@unicode.org> To: unicode@unicode.org Subject: Update to Public Review Issue #109 (Proposed Draft UAX #42) Date: Fri, 16 Nov 2007 15:13:40 -0800 From: Rick McGowan received: by Apple.Mailer (2.95.2) X-archive-position: 278 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: rick@unicode.org Precedence: bulk X-list: cldr-users Proposed Draft UAX #42: Unicode Character Database in XML The draft document for Public Review Issue #109 has been updated. The closing date for review remains 2008-01-28. This draft UAX describes an XML representation of the Unicode Character Database, and is available for public review and comment. Details are on the review page, and the background document for the PRI: http://www.unicode.org/review/ http://www.unicode.org/review/pri-109.html If you have comments for official UTC consideration, please post them by submitting your comments through our feedback & reporting page: http://www.unicode.org/reporting.html If you wish to discuss issues on the Unicode mail list, then please use the following link to subscribe (if necessary). Please be aware that discussion comments on the Unicode mail list are not automatically recorded as input to the UTC. You must use the reporting link above to generate comments for UTC consideration. http://www.unicode.org/consortium/distlist.html Regards, Rick McGowan Unicode, Inc. From rick@unicode.org Fri Nov 16 18:16:15 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 16 Nov 2007 18:19:35 -0600 (CST) Received: from izanami (c-71-202-247-55.hsd1.ca.comcast.net [71.202.247.55]) by unicode.org (8.12.11/8.12.11) with SMTP id lAH0G5Eu027860; Fri, 16 Nov 2007 18:16:06 -0600 Message-Id: <200711170016.lAH0G5Eu027860@unicode.org> To: unicode@unicode.org Subject: Public Reivew Issue #117: UAX #38 The Unicode Han Database Date: Fri, 16 Nov 2007 16:16:06 -0800 From: Rick McGowan received: by Apple.Mailer (2.95.2) X-archive-position: 279 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: rick@unicode.org Precedence: bulk X-list: cldr-users The Unicode Technical Committee has posted a new issue for public review and comment. Details are on the following web page: http://www.unicode.org/review/ Review period for the new item closes on January 28, 2008. Please see the page for links to discussion and relevant documents. Briefly, the new issue is: Public Review Issue #117 Proposed update to UAX #38 The Unicode Han Database (Unihan) Changes in this proposed update include: * Changing document type from UTR to UAX * Corrections made to some regular expressions * Miscellaneous corrections of layout problems and typographical errors If you have comments for official consideration, please post them by submitting your comments through our feedback & reporting page: http://www.unicode.org/reporting.html If you wish to discuss beta issues on the Unicode mail list, then please use the following link to subscribe (if necessary). Please be aware that discussion comments on the Unicode mail list are not automatically recorded as beta comments. You must use the reporting link above to generate comments for official consideration. http://www.unicode.org/consortium/distlist.html Regards, Rick McGowan Unicode, Inc. From rick@unicode.org Fri Nov 16 18:44:36 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Fri, 16 Nov 2007 18:47:49 -0600 (CST) Received: from izanami (c-71-202-247-55.hsd1.ca.comcast.net [71.202.247.55]) by unicode.org (8.12.11/8.12.11) with SMTP id lAH0iW3B016866; Fri, 16 Nov 2007 18:44:33 -0600 Message-Id: <200711170044.lAH0iW3B016866@unicode.org> To: unicode@unicode.org Subject: Unicode Version 5.1 Beta Release Date: Fri, 16 Nov 2007 16:44:33 -0800 From: Rick McGowan received: by Apple.Mailer (2.95.2) X-archive-position: 280 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: rick@unicode.org Precedence: bulk X-list: cldr-users The next version of the Unicode Standard will be Version 5.1.0. The beta version of the documentation for Unicode 5.1.0 is located in: http://www.unicode.org/versions/Unicode5.1.0/ A page describing the beta release is located here: http://www.unicode.org/versions/beta.html This version is planned for release in March 2008. A beta version of the 5.1.0 Unicode Character Database files is also available for public comment. We strongly encourage implementers to download these files and test them with their programs, well before the end of the beta period. See the beta page for access to the files. Any comments on the beta Unicode 5.1.0, the UCD 5.1.0, or the 5.1.0 UAXes should be reported using the Unicode reporting form. The comment period ends January 28, 2008. All substantive comments must be received by that date for consideration at the next UTC meeting. Editorial comments (typos, etc) may be submitted after that date for consideration in the final editorial work. Note: All beta files may be updated, replaced, or superseded by other files at any time. The beta files will be discarded once Unicode 5.1.0 is final. It is inappropriate to cite these files as other than a work in progress. The Unicode Consortium provides early access to updated versions of the data files and text to give reviewers and developers as much time as possible to ensure a problem-free adoption of version 5.1.0. The assignment of characters for Unicode 5.1.0 is now stable. There will be no further additions or modifications of code points. One of the main purposes of the beta review period, however, is to verify and correct the preliminary character property assignments in the Unicode Character Database. Reviewers should check for property changes to existing Unicode 5.0.0 characters, as well as the property values for the new Unicode 5.1.0 character additions. The beta review period is a good opportunity to add support for the new Unicode 5.1.0 characters in internal versions of software, so that software can be tested to verify that the new characters and property assignments don't cause problems when upgraded to Version 5.1.0 of Unicode. In particular, check carefully for any hard-coded range assumptions about Unified CJK Ideographs, because the end range for those has changed from U+9FBB to U+9FC3 in this version. However, because the Unicode Character Database files will be updated during the beta review period, before the final Version 5.1.0 is released, no products or implementations should be released based on the beta data files. For released products, use the final, approved Version 5.1.0 data files, expected in March, 2008. To facilitate the migration of products to the final release version of the Unicode Character Database files, dated, diffable XML versions of the Unicode Character Database will be made available, so that implementers can check the details of any changes that occurred during the beta review period. ------------ If you have comments for official consideration, please post them by submitting your comments through our feedback & reporting page: http://www.unicode.org/reporting.html If you wish to discuss beta issues on the Unicode mail list, then please use the following link to subscribe (if necessary). Please be aware that discussion comments on the Unicode mail list are not automatically recorded as beta comments. You must use the reporting link above to generate comments for official consideration. http://www.unicode.org/consortium/distlist.html Regards, Rick McGowan Unicode, Inc. From mark.edward.davis@gmail.com Tue Nov 27 19:59:21 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 27 Nov 2007 19:59:21 -0600 (CST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by unicode.org (8.12.11/8.12.11) with ESMTP id lAS1xKYi028966 for ; Tue, 27 Nov 2007 19:59:20 -0600 Received: by wa-out-1112.google.com with SMTP id j40so1671589wah for ; Tue, 27 Nov 2007 17:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=UQgfZvsVOFeVJw4S/y7koz23sPkAad4Jw8NFCV1DnSY=; b=ntYCcz6YjYNqsg4QE+LYwieeH2vK+aZgaMFDtheQ8aM7uq/n3LvohJdCGnjYx+AoXvwgalNUKwCL7cTNc5OJzQ6xWSRTz9YximKULuaP8S+APSKEVONUUOW8u16x5Eo43npFqWNxstDojEXsCd7qiSj9elJUy1O+Ijr0g9cmnok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=v5C/lzZblBVN56rIDvSyXmV2+0bySTaS+QcRvDvhkoEZiVVvWw4OZhNBkh4qaozeeiWdgnxNzj5RAG2T3edATcJibJduUwnF0lbIpJkU5DvWP6edOQ+WmY/AVhOJEFBfzxjdVpWu0lQpos3LkJMel218+FkxqBnruxQetmZoCbI= Received: by 10.114.160.1 with SMTP id i1mr248411wae.1196215160116; Tue, 27 Nov 2007 17:59:20 -0800 (PST) Received: by 10.114.198.8 with HTTP; Tue, 27 Nov 2007 17:59:20 -0800 (PST) Message-ID: <30b660a20711271759h7cc95ab5le94ef2239ddf97ce@mail.gmail.com> Date: Tue, 27 Nov 2007 17:59:20 -0800 From: "Mark Davis" To: "CLDR list" , cldr-users@unicode.org Subject: New version of tr35 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1749_8734169.1196215160111" X-Google-Sender-Auth: 23e48589de218924 X-archive-position: 281 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: mark.davis@icu-project.org Precedence: bulk X-list: cldr-users ------=_Part_1749_8734169.1196215160111 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline There is a draft version of TR#35 (Unicode LDML) on http://unicode.org/draft/reports/tr35/tr35.html, for the CLDR 1.5.1 release (coming up very soon). This release is primarily bug fixes, with some small additions of structure, and only very few changes in localizations. The main changes to the specification are listed under http://unicode.org/draft/reports/tr35/tr35.html#Modifications - Extensive rewrite in Appendix J: Time Zone Display Names, primarily due to refinements to the metazone process. This also caused some changes in Appendix F: Date Format Patterns. - Made the date range handling uniform, with new Section 5.2.1 Dates and Date Ranges, and related changes particularly to C.1 and C.5 in Appendix C: Supplemental Data. - Added C10. Likely Subtags Feedback is welcome, and can be filed at http://www.unicode.org/cldr/bugs/locale-bugs or discussed on cldr-users@unicode.org. Access to the draft 1.5.1 data is described under CVS Access under http://www.unicode.org/cldr/repository_access.html. -- Mark ------=_Part_1749_8734169.1196215160111 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline There is a draft version of TR#35 (Unicode LDML)  on http://unicode.org/draft/reports/tr35/tr35.html, for the CLDR 1.5.1 release (coming up very soon). This release is primarily bug fixes, with some small additions of structure, and only very few changes in localizations.

The main changes to the specification are listed under http://unicode.org/draft/reports/tr35/tr35.html#Modifications
  • Extensive rewrite in Appendix J: Time Zone Display Names, primarily due to refinements to the metazone process. This also caused some changes in Appendix F: Date Format Patterns.
  • Made the date range handling uniform, with new Section 5.2.1 Dates and Date Ranges, and related changes particularly to C.1 and C.5 in Appendix C: Supplemental Data.
  • Added C10. Likely Subtags
Feedback is welcome, and can be filed at http://www.unicode.org/cldr/bugs/locale-bugs or discussed on cldr-users@unicode.org.

Access to the draft 1.5.1 data is described under CVS Access under http://www.unicode.org/cldr/repository_access.html.

--
Mark ------=_Part_1749_8734169.1196215160111-- From verdy_p@wanadoo.fr Wed Nov 28 00:03:19 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 28 Nov 2007 00:03:21 -0600 (CST) Received: from smtp21.orange.fr (smtp21.orange.fr [80.12.242.48]) by unicode.org (8.12.11/8.12.11) with ESMTP id lAS63Gu2027534 for ; Wed, 28 Nov 2007 00:03:16 -0600 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2114.orange.fr (SMTP Server) with ESMTP id D85771C00090 for ; Wed, 28 Nov 2007 07:03:10 +0100 (CET) Received: from HARNON (unknown [90.50.99.181]) by mwinf2114.orange.fr (SMTP Server) with ESMTP id 6BE591C00087; Wed, 28 Nov 2007 07:03:10 +0100 (CET) X-ME-UUID: 20071128060310442.6BE591C00087@mwinf2114.orange.fr Reply-To: From: "Philippe Verdy" To: "'Mark Davis'" , "'CLDR list'" , References: <30b660a20711271759h7cc95ab5le94ef2239ddf97ce@mail.gmail.com> Subject: RE: New version of tr35 Date: Wed, 28 Nov 2007 07:03:05 +0100 Organization: Ordinateur Personnel Message-ID: <00d401c83184$57ea0de0$0a01a8c0@HARNON> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <30b660a20711271759h7cc95ab5le94ef2239ddf97ce@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgxZUnRshtXiS7FR0KvO+h9Z8AVmgAHGJ8w X-archive-position: 282 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: verdy_p@wanadoo.fr Precedence: bulk X-list: cldr-users > The main changes to the specification are listed under > http://unicode.org/draft/reports/tr35/tr35.html#Modifications > . Extensive rewrite in Appendix J: Time Zone Display Names, > primarily due to refinements to the metazone process. This > also caused some changes in Appendix F: Date Format Patterns. > . Made the date range handling uniform, with new Section 5.2.1 > Dates and Date Ranges, and related changes particularly to > C.1 and C.5 in Appendix C: Supplemental Data. The document fixes restrictions on dates and time, but it specifies that the maximum time specifiable is 24:00:00; but does it accept also 23:59:60 (which is the last second before the end of a day with a leap second, where the last minute of the day counts 61 seconds), or even 23:59:61 (if there's two leap seconds inserted, where the last minute of the day counts 62 seconds, something that has still not occurred but is theoretically possible according to the BIPM that currently inserts leap seconds every 6 or 9 months)? Note also that leap seconds may also be exceptionally subtracted at end of the last minute of the day, if the earth rotation accelerates a bit (also theoretically possible, but should occur exceptionally only because of cosmological events, or some major earthquakes producing a huge tsunami, something could impact the rotation of Earth around the Sun, and its own rotation speed; such acceleration should only be temporary and would be reverted on the nest months, probably requiring the reinsertion of two leap seconds instead of one). Today, we have very precise synchronized clocks all around the world, because we need them for the navigation and GPS or satellite systems for precise positioning, so it should not be exceptional to find such coordinated times generated and present in such files. Normally such exceptional time precision should not be needed within locale data, but it may be needed in some supplementary data mapping the UTC time with other national time. From srl@icu-project.org Wed Nov 28 02:14:15 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 28 Nov 2007 02:14:15 -0600 (CST) Received: from k2smtpout05-02.prod.mesa1.secureserver.net (k2smtpout05-02.prod.mesa1.secureserver.net [64.202.189.57]) by unicode.org (8.12.11/8.12.11) with SMTP id lAS8EEps032765 for ; Wed, 28 Nov 2007 02:14:14 -0600 Received: (qmail 21327 invoked from network); 28 Nov 2007 08:14:13 -0000 Received: from unknown (HELO ssl.icu-project.org) (208.109.248.225) by k2smtpout05-02.prod.mesa1.secureserver.net (64.202.189.57) with ESMTP; 28 Nov 2007 08:14:13 -0000 Received: from monkey.sbay.org ([216.27.178.44] helo=tintin.priv) by ssl.icu-project.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.62) (envelope-from ) id 1IxI3h-00020M-AI; Wed, 28 Nov 2007 00:14:13 -0800 Cc: cldr-users@unicode.org Message-Id: From: "Steven R. Loomis" To: In-Reply-To: <00d401c83184$57ea0de0$0a01a8c0@HARNON> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: New version of tr35 Date: Wed, 28 Nov 2007 00:14:12 -0800 References: <30b660a20711271759h7cc95ab5le94ef2239ddf97ce@mail.gmail.com> <00d401c83184$57ea0de0$0a01a8c0@HARNON> X-Mailer: Apple Mail (2.915) X-archive-position: 283 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: srl@icu-project.org Precedence: bulk X-list: cldr-users UTC may abolish the use of leap seconds by 2013 http://www.navcen.uscg.gov/cgsic/meetings/47thMeeting/%5B16%5D%20CGSIC47-WL%20General_md.pdf In any event, I think the question is whether the *time zone transition point* would need to be specified in terms of a leap second. I don't think CLDR addresses leap seconds, nor is 24:00:00 something which would be specified as an output format. I agree that the precision can be useful, but I question whether it is useful in time zone specifications. perhaps you should suggest other precisions and uses for cldr? regards, Steven On 27 Nov 2007, at 22:03, Philippe Verdy wrote: >> The main changes to the specification are listed under >> http://unicode.org/draft/reports/tr35/tr35.html#Modifications >> . Extensive rewrite in Appendix J: Time Zone Display Names, >> primarily due to refinements to the metazone process. This >> also caused some changes in Appendix F: Date Format Patterns. >> . Made the date range handling uniform, with new Section 5.2.1 >> Dates and Date Ranges, and related changes particularly to >> C.1 and C.5 in Appendix C: Supplemental Data. > > The document fixes restrictions on dates and time, but it specifies > that the > maximum time specifiable is 24:00:00; but does it accept also 23:59:60 > (which is the last second before the end of a day with a leap > second, where > the last minute of the day counts 61 seconds), or even 23:59:61 (if > there's > two leap seconds inserted, where the last minute of the day counts 62 > seconds, something that has still not occurred but is theoretically > possible > according to the BIPM that currently inserts leap seconds every 6 or 9 > months)? > > Note also that leap seconds may also be exceptionally subtracted at > end of > the last minute of the day, if the earth rotation accelerates a bit > (also > theoretically possible, but should occur exceptionally only because of > cosmological events, or some major earthquakes producing a huge > tsunami, > something could impact the rotation of Earth around the Sun, and its > own > rotation speed; such acceleration should only be temporary and would > be > reverted on the nest months, probably requiring the reinsertion of > two leap > seconds instead of one). > > Today, we have very precise synchronized clocks all around the world, > because we need them for the navigation and GPS or satellite systems > for > precise positioning, so it should not be exceptional to find such > coordinated times generated and present in such files. > > Normally such exceptional time precision should not be needed within > locale > data, but it may be needed in some supplementary data mapping the > UTC time > with other national time. From verdy_p@wanadoo.fr Wed Nov 28 06:23:28 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 28 Nov 2007 06:23:28 -0600 (CST) Received: from smtp21.orange.fr (smtp21.orange.fr [80.12.242.47]) by unicode.org (8.12.11/8.12.11) with ESMTP id lASCNSi9001574 for ; Wed, 28 Nov 2007 06:23:28 -0600 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2109.orange.fr (SMTP Server) with ESMTP id 8F7021C00093 for ; Wed, 28 Nov 2007 13:23:22 +0100 (CET) Received: from HARNON (unknown [90.50.99.181]) by mwinf2109.orange.fr (SMTP Server) with ESMTP id 304621C00087; Wed, 28 Nov 2007 13:23:22 +0100 (CET) X-ME-UUID: 20071128122322197.304621C00087@mwinf2109.orange.fr Reply-To: From: "Philippe Verdy" To: "'Steven R. Loomis'" Cc: References: <30b660a20711271759h7cc95ab5le94ef2239ddf97ce@mail.gmail.com> <00d401c83184$57ea0de0$0a01a8c0@HARNON> Subject: RE: New version of tr35 Date: Wed, 28 Nov 2007 13:23:17 +0100 Organization: Ordinateur Personnel Message-ID: <00ea01c831b9$74b18180$0a01a8c0@HARNON> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgxmUlT6rRQydNvTjO4E/t1CpbqSAAHZeFA X-archive-position: 284 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: verdy_p@wanadoo.fr Precedence: bulk X-list: cldr-users Steven R. Loomis wrote: > UTC may abolish the use of leap seconds by 2013 > http://www.navcen.uscg.gov/cgsic/meetings/47thMeeting/%5B16%5D%20CGS > IC47-WL%20General_md.pdf Is it a joke? Leap seconds are needed to make sure that the duration of the second is not modified by the constant change of Earth rotation speed which affects the duration of the day, and by the fact that calendars need to remain synchronized with the Earth rotation. So calendar days are not necessarily 24 hours long, but the second remains unaffected. Leap seconds are the solution. The Earth will not stop changing its rotation speed in 2013... And I have real doubts that our official times will become desynchronized with the calendar (meaning here that the terrestrial day could start at 00:00:12 and end at 24:00:11 for example). And really, how can you know what the UTC will decide in 2013? Against the international agreement about the maintenance of the calendar by the BIPM? May be you are referring to something else when speaking about the UTC: in this list it refers to the Unicode Technical Committee, but you may speak here about the Universal Coordinated Time. What could happen is that the UTC time would be defined according to the astronomic time (where days have a constant length of 24 hours, but days are NOT referenced by their calendar mapping, but by a difference from an arbitrary origin computed with a constant day of 24 hours). Even if this occurs, there will remain the need to use a coordinated calendar time that uses leap seconds, needed for the further definition of legal time, and for many practical reasons: nobody on Earth would likely use such astronomical time where midday would gradually move into the middle of the night! So let's assume that UTC time disappears, then each country would still define its timezones by requiring them to use their own mapping from astronomical time. If each country need to define their own mapping, then the conversion of local time from one country to another using a different timezone would become a nightmare (and many existing computing protocols that use UTC time for tracking timestamps would have to be changed to use astronomical time, with complex conversion rules needed to display the correct local date and time). Really, your document is not speaking about abolishing leap seconds in UTC, but for some applications, like navigation systems, to use astronomical time (in fact TAI, "Temps Atomique International") instead within satellite navigation systems (and let them applications compute local date-time if needed, something not necessary for navigation). From cfynn@gmx.net Wed Nov 28 07:03:01 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 28 Nov 2007 07:03:01 -0600 (CST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by unicode.org (8.12.11/8.12.11) with SMTP id lASD30j1018398 for ; Wed, 28 Nov 2007 07:03:01 -0600 Received: (qmail invoked by alias); 28 Nov 2007 13:02:52 -0000 Received: from cust71.fastlink.bt (EHLO [127.0.0.1]) [202.89.26.71] by mail.gmx.net (mp036) with SMTP; 28 Nov 2007 14:02:52 +0100 X-Authenticated: #9568751 X-Provags-ID: V01U2FsdGVkX19rGdhDCwhrMZyMa2VJq3FmFvHOvWxyB16gWHeXcj XAay0+sKMuGBgF Message-ID: <474D66DF.7040505@gmx.net> Date: Wed, 28 Nov 2007 19:02:23 +0600 From: Christopher Fynn User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: verdy_p@wanadoo.fr, cldr-users@unicode.org Subject: Re: New version of tr35 References: <30b660a20711271759h7cc95ab5le94ef2239ddf97ce@mail.gmail.com> <00d401c83184$57ea0de0$0a01a8c0@HARNON> In-Reply-To: <00d401c83184$57ea0de0$0a01a8c0@HARNON> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071127-0, 27/11/2007), Outbound message X-Antivirus-Status: Clean X-Y-GMX-Trusted: 0 X-archive-position: 285 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: cfynn@gmx.net Precedence: bulk X-list: cldr-users Philippe Verdy wrote: > The document fixes restrictions on dates and time, but it specifies that the > maximum time specifiable is 24:00:00; but does it accept also 23:59:60 > (which is the last second before the end of a day with a leap second, where > the last minute of the day counts 61 seconds), or even 23:59:61 (if there's > two leap seconds inserted, where the last minute of the day counts 62 > seconds, something that has still not occurred but is theoretically possible > according to the BIPM that currently inserts leap seconds every 6 or 9 > months)? Philippe While I understand the point you are making, MS Windows doesn't seem to let you set the system time to 23:59:60 (or even 24:00:00) - how about other operating systems & BIOS? Since a locale is something used by the operating system or applications to display date or time in localized format is there any point in CLDR allowing for times that operating systems and applications cannot handle? Might not allowing values > 23:59:59 cause conflicts? I'm wondering - if you connect to a time sync server like time.nist.gov at the very moment a leap second is inserted do they actually transmit a time like 23:59:60:nn - or do they just do something like go off line for a second or transmit 23:59:59:nn for two seconds?? - Chris From verdy_p@wanadoo.fr Wed Nov 28 07:38:55 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 28 Nov 2007 07:38:55 -0600 (CST) Received: from smtp21.orange.fr (smtp21.orange.fr [80.12.242.49]) by unicode.org (8.12.11/8.12.11) with ESMTP id lASDcskP001865 for ; Wed, 28 Nov 2007 07:38:54 -0600 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2124.orange.fr (SMTP Server) with ESMTP id 7F1541C000BF for ; Wed, 28 Nov 2007 14:38:48 +0100 (CET) Received: from HARNON (unknown [90.50.99.181]) by mwinf2124.orange.fr (SMTP Server) with ESMTP id 39BA61C000B2; Wed, 28 Nov 2007 14:38:48 +0100 (CET) X-ME-UUID: 20071128133848236.39BA61C000B2@mwinf2124.orange.fr Reply-To: From: "Philippe Verdy" To: "'Christopher Fynn'" , References: <30b660a20711271759h7cc95ab5le94ef2239ddf97ce@mail.gmail.com> <00d401c83184$57ea0de0$0a01a8c0@HARNON> <474D66DF.7040505@gmx.net> Subject: RE: New version of tr35 Date: Wed, 28 Nov 2007 14:38:43 +0100 Organization: Ordinateur Personnel Message-ID: <00ee01c831c3$fe5f2090$0a01a8c0@HARNON> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <474D66DF.7040505@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acgxvv2z0pQ5IrqvTimuDrPvaCZbmgAAJoFg Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id lASDcskP001865 X-archive-position: 286 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: verdy_p@wanadoo.fr Precedence: bulk X-list: cldr-users > De : Christopher Fynn [mailto:cfynn@gmx.net] > Envoyé : mercredi 28 novembre 2007 14:02 > À : verdy_p@wanadoo.fr; cldr-users@unicode.org > Objet : Re: New version of tr35 > > Philippe Verdy wrote: > > > The document fixes restrictions on dates and time, but it specifies that > the > > maximum time specifiable is 24:00:00; but does it accept also 23:59:60 > > (which is the last second before the end of a day with a leap second, > where > > the last minute of the day counts 61 seconds), or even 23:59:61 (if > there's > > two leap seconds inserted, where the last minute of the day counts 62 > > seconds, something that has still not occurred but is theoretically > possible > > according to the BIPM that currently inserts leap seconds every 6 or 9 > > months)? It's not a problem: BIOS and Oses are using something else to adjust the effective UTC time to a local-only time using drafting seconds (this means that their clock is not using true seconds). The main problem of such adjustments is that there's NO standard for such drifting, so each system implements these local adjustments using their own algorithm and tuning parameters. This affects the precision of their time measurement for a very small fraction of the second, it is not visible to most users, but the difference is visible if you consider the internal CPU clock cycles counters: the locally computed drifting time is reporting some seconds that count more CPU cycles than others. What is proposed in this system: adopting recalibrated seconds, will have a severe impact, as it will change the definition of the second used in those satellite systems. My opinion is that they should no longer call it a "second", because the definition of the absolute second is needed for calibrating almost other physical units in the SI. I just wonder why such suggestion has been made. Instead, the absolute second should really be kept unchanged, and satellite navigation systems just need to broadcast timestamps using TAI, possibly broadcasting an informative data for helping converting it to UTC. But let's remember alko that satellites also don't have a regular movement around the Earth: their rotation vary, is subject to variation of pressure and perturbations in the tiny upper atmosphere, or are subject to the solar wind and flows of particles, or variation in the magnetosphere; in addition, their altitude is constantly decreasing, and their rotation speed decelerating so the satellites must regularly be "boosted" again in their orbit to avoid falling early onto Earth... After each such adjustment, their terrestrial reference needs to be changed, as well as the parameters they are broadcasting to terrestrial navigation system receptors that use this information to compute terrestrial positions. But using a unspecified drifting second in those systems will certainly not help implementing the computing algorithms, given that the terrestrial receptors will still be measing time differences using absolute seconds. Initially Galileo intended to use the TAI clock as its reference time frame, but then moved to use UTC for compatibility with the GPS. This was (in my opinion) a design error in the GPS system, and I don't understand the position in this document of trying to adopt a system with a unspecified drifting second instead of the SI unit currently used in both UTC and TAI!! Drifting seconds (using a continuous timescale) should just be a local adjustment, but it should not even impact the measurement of absolute seconds (as defined in TAI and still used in UTC), notably because there's absolutely no standard defining how seconds are adjusted, and what is the precision of such local drifting adjustments (this means that the small differences in fractions of seconds between two "continuous scales" will be constantly changing at different times, an unpredictably from one system to another, and the result will be even worse)! I personnally do like the concept of leap seconds, because it preserves the SI units. Trying to solve an existing problem in BIOS or OSes by changing the time reference is the wrong way to go: this limitation is an implementation defect, that should be corrected in softwares! The reality IS that the duration of terrestrial days is constantly changing, and we must admit that a calendar day is not necessarily exactly 24 hours (in fact is NOT, and may even have never been 24 hours exactly, i.e. 24*60*60 SI seconds!) If leap seconds have been less used and heard of by implementers since some years, it's just because the deceleration of Earth rotation has slowed down in the recent period, meaning that there were less frequent insertions of leap seconds. This is ONLY temporary! In the next 10 years, we'll need more leap seconds because the Earth will restart decelerating at higher rate, meaning that more frequent leap seconds will be needed (we don't have a very long history of measurements of the Earth rotation variations, but what is now asserted, is that this rotation speed is very irregular and depends on a lot of factors, not all of them endogen but caused for example by solar activity, or by the seasonal traversal of the Earth of "clouds" of dusts). So please don't use the excuse of BIOS and Windows limitations. Let's admit that a local time 23:59:60 or 23:59:61 is possible and not necessarily equal to 24:00:00. Let's accept that the terrestrial day is not 24 hours exactly, but let's keep our calendars synchronized with Earth rotation. Trying to convince everybody that a terrestrial calendar day is now exactly 24 hours will mean that you have changed the definition of the second, a really bad decision that will have other severe impacts in physics for all other measurements when people won't remember that this variable second is distinct from the absolute and immutable physical second! From verdy_p@wanadoo.fr Wed Nov 28 07:46:02 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 28 Nov 2007 07:46:02 -0600 (CST) Received: from smtp21.orange.fr (smtp21.orange.fr [80.12.242.49]) by unicode.org (8.12.11/8.12.11) with ESMTP id lASDk1KT003995 for ; Wed, 28 Nov 2007 07:46:02 -0600 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2124.orange.fr (SMTP Server) with ESMTP id 670661C000A3 for ; Wed, 28 Nov 2007 14:45:56 +0100 (CET) Received: from HARNON (unknown [90.50.99.181]) by mwinf2124.orange.fr (SMTP Server) with ESMTP id 2B4BF1C0009C; Wed, 28 Nov 2007 14:45:56 +0100 (CET) X-ME-UUID: 20071128134556177.2B4BF1C0009C@mwinf2124.orange.fr Reply-To: From: "Philippe Verdy" To: "'Christopher Fynn'" , References: <30b660a20711271759h7cc95ab5le94ef2239ddf97ce@mail.gmail.com> <00d401c83184$57ea0de0$0a01a8c0@HARNON> <474D66DF.7040505@gmx.net> Subject: RE: New version of tr35 Date: Wed, 28 Nov 2007 14:45:51 +0100 Organization: Ordinateur Personnel Message-ID: <00ef01c831c4$fd6a1cc0$0a01a8c0@HARNON> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <474D66DF.7040505@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acgxwcq+mUQDufpTS8eDK2xvDIDGHAAAkIAA X-archive-position: 287 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: verdy_p@wanadoo.fr Precedence: bulk X-list: cldr-users Christopher Fynn wrote: > I'm wondering - if you connect to a time sync server like time.nist.gov at > the > very moment a leap second is inserted do they actually transmit a time > like > 23:59:60:nn - or do they just do something like go off line for a second > or > transmit 23:59:59:nn for two seconds?? The NIST time serves are reporting not just the exact UTC time, but also when the current day includes leap seconds, and how much. It also reports when the next leap seconds will be inserted, so the system can predict when this will occur. Then it's up to the system using this UTC time to adjust their clock so that it matches more or less closely the UTC time: they can either use UTC time, or using a local-only drifting adjustment if they opt for a continuous scale. But these systems using drifting seconds can't be used as time references, because their local-only adjustments are unpredictable: Many systems will simply abruptly adjust their local clock (if they see 23:59:60 or 23:50:61, they round it simply to 24:00:00 or to 23:59:59), others will compensate the difference with UTC by drifting their local time for a period spanning several minutes or several hours, or several days, depending on the implementation and the precision of the drifting adjustment counters, and possibly the history of their past adjustments! What they do locally to compensate is all but defined by an approved standard. From srl@icu-project.org Wed Nov 28 09:59:52 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 28 Nov 2007 09:59:52 -0600 (CST) Received: from k2smtpout05-01.prod.mesa1.secureserver.net (k2smtpout05-01.prod.mesa1.secureserver.net [64.202.189.56]) by unicode.org (8.12.11/8.12.11) with SMTP id lASFxpii006551 for ; Wed, 28 Nov 2007 09:59:52 -0600 Received: (qmail 26290 invoked from network); 28 Nov 2007 15:59:51 -0000 Received: from unknown (HELO ssl.icu-project.org) (208.109.248.225) by k2smtpout05-01.prod.mesa1.secureserver.net (64.202.189.56) with ESMTP; 28 Nov 2007 15:59:51 -0000 Received: from monkey.sbay.org ([216.27.178.44] helo=tintin.priv) by ssl.icu-project.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.62) (envelope-from ) id 1IxPKI-0004Sd-TW; Wed, 28 Nov 2007 07:59:51 -0800 Cc: "'Christopher Fynn'" , Message-Id: From: "Steven R. Loomis" To: In-Reply-To: <00ee01c831c3$fe5f2090$0a01a8c0@HARNON> Content-Type: multipart/alternative; boundary=Apple-Mail-20-1062540079 Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: New version of tr35 Date: Wed, 28 Nov 2007 07:59:48 -0800 References: <30b660a20711271759h7cc95ab5le94ef2239ddf97ce@mail.gmail.com> <00d401c83184$57ea0de0$0a01a8c0@HARNON> <474D66DF.7040505@gmx.net> <00ee01c831c3$fe5f2090$0a01a8c0@HARNON> X-Mailer: Apple Mail (2.915) X-archive-position: 288 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: srl@icu-project.org Precedence: bulk X-list: cldr-users --Apple-Mail-20-1062540079 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable ( If we are modifying what 'normal' users actually see, a more useful =20= change might be to do away with daylight savings time or summer time. =20= Otherwise we are ignoring hours to worry about seconds, as far as the =20= difference between clocks and reality. ) But I think the discussion about BIOS and OS limitation brings this =20 back to how this relates to CLDR: CLDR's primary focus is, generally =20= and broadly speaking, supplying the locale data and usage information =20= used by general purpose operating systems, and applications. These =20 are, as you know, typically are concerned with converting a clock =20 value (the length of time since a certain epoch - ignoring leap =20 seconds) to and from a human readable time-of-day measurement. For =20 these applications, they are mostly not concerned that the difference =20= between Jan 1 2000 and Jan 1 2007 is incorrect in the absolute =20 difference counting seconds versus days. Not so, as you said, =20 navigation etc. As I said, I think you want to propose an alternative =20= to - not a modification to - wall time to be used in those =20 applications. Perhaps some sort of symbol or description to state =20 that recalibrated seconds are used, and some indication of drift. I understand the astrophysical reality, but the reality is also that =20 the time scale of 24*60*60 is what most people expect and live in. =20 (Although with daylight savings time, it is sometimes 23 and sometimes =20= 25 hours long.) That is what individuals and organizations expect from =20= locale data. The PDF I sent you before was not a joke. I am less familiar with the =20= details, but it is a BIPM presentation theorizing about the =20 possibility of ceasing to apply leap seconds to UTC by 2013. -s On 28 Nov 2007, at 05:38, Philippe Verdy wrote: >> De : Christopher Fynn [mailto:cfynn@gmx.net] >> Envoy=E9 : mercredi 28 novembre 2007 14:02 >> =C0 : verdy_p@wanadoo.fr; cldr-users@unicode.org >> Objet : Re: New version of tr35 >> >> Philippe Verdy wrote: >> >>> The document fixes restrictions on dates and time, but it =20 >>> specifies that >> the >>> maximum time specifiable is 24:00:00; but does it accept also =20 >>> 23:59:60 >>> (which is the last second before the end of a day with a leap =20 >>> second, >> where >>> the last minute of the day counts 61 seconds), or even 23:59:61 (if >> there's >>> two leap seconds inserted, where the last minute of the day counts =20= >>> 62 >>> seconds, something that has still not occurred but is theoretically >> possible >>> according to the BIPM that currently inserts leap seconds every 6 =20= >>> or 9 >>> months)? > > It's not a problem: BIOS and Oses are using something else to adjust =20= > the > effective UTC time to a local-only time using drafting seconds (this =20= > means > that their clock is not using true seconds). > > The main problem of such adjustments is that there's NO standard for =20= > such > drifting, so each system implements these local adjustments using =20 > their own > algorithm and tuning parameters. This affects the precision of their =20= > time > measurement for a very small fraction of the second, it is not =20 > visible to > most users, but the difference is visible if you consider the =20 > internal CPU > clock cycles counters: the locally computed drifting time is =20 > reporting some > seconds that count more CPU cycles than others. > > What is proposed in this system: adopting recalibrated seconds, will =20= > have a > severe impact, as it will change the definition of the second used =20 > in those > satellite systems. My opinion is that they should no longer call it a > "second", because the definition of the absolute second is needed for > calibrating almost other physical units in the SI. > > I just wonder why such suggestion has been made. Instead, the absolute > second should really be kept unchanged, and satellite navigation =20 > systems > just need to broadcast timestamps using TAI, possibly broadcasting an > informative data for helping converting it to UTC. > > But let's remember alko that satellites also don't have a regular =20 > movement > around the Earth: their rotation vary, is subject to variation of =20 > pressure > and perturbations in the tiny upper atmosphere, or are subject to =20 > the solar > wind and flows of particles, or variation in the magnetosphere; in =20 > addition, > their altitude is constantly decreasing, and their rotation speed > decelerating so the satellites must regularly be "boosted" again in =20= > their > orbit to avoid falling early onto Earth... > > After each such adjustment, their terrestrial reference needs to be =20= > changed, > as well as the parameters they are broadcasting to terrestrial =20 > navigation > system receptors that use this information to compute terrestrial =20 > positions. > But using a unspecified drifting second in those systems will =20 > certainly not > help implementing the computing algorithms, given that the terrestrial > receptors will still be measing time differences using absolute =20 > seconds. > > Initially Galileo intended to use the TAI clock as its reference =20 > time frame, > but then moved to use UTC for compatibility with the GPS. This was =20 > (in my > opinion) a design error in the GPS system, and I don't understand the > position in this document of trying to adopt a system with a =20 > unspecified > drifting second instead of the SI unit currently used in both UTC =20 > and TAI!! > > Drifting seconds (using a continuous timescale) should just be a local > adjustment, but it should not even impact the measurement of absolute > seconds (as defined in TAI and still used in UTC), notably because =20 > there's > absolutely no standard defining how seconds are adjusted, and what =20 > is the > precision of such local drifting adjustments (this means that the =20 > small > differences in fractions of seconds between two "continuous scales" =20= > will be > constantly changing at different times, an unpredictably from one =20 > system to > another, and the result will be even worse)! > > I personnally do like the concept of leap seconds, because it =20 > preserves the > SI units. Trying to solve an existing problem in BIOS or OSes by =20 > changing > the time reference is the wrong way to go: this limitation is an > implementation defect, that should be corrected in softwares! The =20 > reality IS > that the duration of terrestrial days is constantly changing, and we =20= > must > admit that a calendar day is not necessarily exactly 24 hours (in =20 > fact is > NOT, and may even have never been 24 hours exactly, i.e. 24*60*60 SI > seconds!) > > If leap seconds have been less used and heard of by implementers =20 > since some > years, it's just because the deceleration of Earth rotation has =20 > slowed down > in the recent period, meaning that there were less frequent =20 > insertions of > leap seconds. This is ONLY temporary! In the next 10 years, we'll =20 > need more > leap seconds because the Earth will restart decelerating at higher =20 > rate, > meaning that more frequent leap seconds will be needed (we don't =20 > have a very > long history of measurements of the Earth rotation variations, but =20 > what is > now asserted, is that this rotation speed is very irregular and =20 > depends on a > lot of factors, not all of them endogen but caused for example by =20 > solar > activity, or by the seasonal traversal of the Earth of "clouds" of =20 > dusts). > > So please don't use the excuse of BIOS and Windows limitations. =20 > Let's admit > that a local time 23:59:60 or 23:59:61 is possible and not =20 > necessarily equal > to 24:00:00. Let's accept that the terrestrial day is not 24 hours =20 > exactly, > but let's keep our calendars synchronized with Earth rotation. =20 > Trying to > convince everybody that a terrestrial calendar day is now exactly 24 =20= > hours > will mean that you have changed the definition of the second, a =20 > really bad > decision that will have other severe impacts in physics for all other > measurements when people won't remember that this variable second is > distinct from the absolute and immutable physical second! --Apple-Mail-20-1062540079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
( If we are modifying = what 'normal' users actually see, a more useful change might be to do = away with daylight savings time or summer time. Otherwise we are = ignoring hours to worry about seconds, as far as the difference between = clocks and reality. )

But I think the discussion = about BIOS and OS limitation brings this back to how this relates to = CLDR:  CLDR's primary focus is, generally and broadly speaking, = supplying the locale data and usage information used by general purpose = operating systems, and applications.  These are, as you know, = typically are concerned with converting a clock value (the length of = time since a certain epoch - ignoring leap seconds) to and from a human = readable time-of-day measurement.  For these applications, they are = mostly not concerned that the difference between Jan 1 2000 and Jan 1 = 2007 is incorrect in the absolute difference counting seconds versus = days.  Not so, as you said, navigation etc.  As I said, I = think you want to propose an alternative to - not a modification to - = wall time to be used in those applications.   Perhaps some sort of = symbol or description to state that recalibrated seconds are used, and = some indication of drift.

I understand the = astrophysical reality, but the reality is also that the time scale of = 24*60*60 is what most people expect and live in. (Although with daylight = savings time, it is sometimes 23 and sometimes 25 hours long.) That is = what individuals and organizations expect from locale = data. 

The PDF I sent you before = was not a joke. I am less familiar with the details, but it is a = BIPM presentation theorizing about the possibility of ceasing = to apply leap seconds to UTC by 2013.

-s

On 28 Nov 2007, at 05:38, = Philippe Verdy wrote:
De : = Christopher Fynn [mailto:cfynn@gmx.net]
Envoy=E9 : mercredi 28 novembre 2007 = 14:02
=C0 : verdy_p@wanadoo.fr; cldr-users@unicode.org
Objet : Re: New version of = tr35

Philippe Verdy = wrote:

The document fixes restrictions on dates and time, but it = specifies that
the
maximum time specifiable is 24:00:00; but does it accept = also 23:59:60
(which is the last second before = the end of a day with a leap = second,
where
the last minute of the day counts 61 seconds), or even = 23:59:61 (if
there's
two leap seconds inserted, where = the last minute of the day counts = 62
seconds, something that has still not occurred but is = theoretically
possible
according to the BIPM that = currently inserts leap seconds every 6 or = 9
months)?

It's not a = problem: BIOS and Oses are using something else to adjust = the
effective UTC time to a local-only time using drafting seconds = (this means
that their clock is not using true seconds).

The = main problem of such adjustments is that there's NO standard for = such
drifting, so each system implements these local adjustments = using their own
algorithm and tuning parameters. This affects the = precision of their time
measurement for a very small fraction of the = second, it is not visible to
most users, but the difference is = visible if you consider the internal CPU
clock cycles counters: the = locally computed drifting time is reporting some
seconds that count = more CPU cycles than others.

What is proposed in this system: = adopting recalibrated seconds, will have a
severe impact, as it will = change the definition of the second used in those
satellite systems. = My opinion is that they should no longer call it a
"second", because = the definition of the absolute second is needed for
calibrating = almost other physical units in the SI.

I just wonder why such = suggestion has been made. Instead, the absolute
second should really = be kept unchanged, and satellite navigation systems
just need to = broadcast timestamps using TAI, possibly broadcasting an
informative = data for helping converting it to UTC.

But let's remember alko = that satellites also don't have a regular movement
around the Earth: = their rotation vary, is subject to variation of pressure
and = perturbations in the tiny upper atmosphere, or are subject to the = solar
wind and flows of particles, or variation in the magnetosphere; = in addition,
their altitude is constantly decreasing, and their = rotation speed
decelerating so the satellites must regularly be = "boosted" again in their
orbit to avoid falling early onto = Earth...

After each such adjustment, their terrestrial reference = needs to be changed,
as well as the parameters they are broadcasting = to terrestrial navigation
system receptors that use this information = to compute terrestrial positions.
But using a unspecified drifting = second in those systems will certainly not
help implementing the = computing algorithms, given that the terrestrial
receptors will still = be measing time differences using absolute seconds.

Initially = Galileo intended to use the TAI clock as its reference time = frame,
but then moved to use UTC for compatibility with the GPS. This = was (in my
opinion) a design error in the GPS system, and I don't = understand the
position in this document of trying to adopt a system = with a unspecified
drifting second instead of the SI unit currently = used in both UTC and TAI!!

Drifting seconds (using a continuous = timescale) should just be a local
adjustment, but it should not even = impact the measurement of absolute
seconds (as defined in TAI and = still used in UTC), notably because there's
absolutely no standard = defining how seconds are adjusted, and what is the
precision of such = local drifting adjustments (this means that the small
differences in = fractions of seconds between two "continuous scales" will = be
constantly changing at different times, an unpredictably from one = system to
another, and the result will be even worse)!

I = personnally do like the concept of leap seconds, because it preserves = the
SI units. Trying to solve an existing problem in BIOS or OSes by = changing
the time reference is the wrong way to go: this limitation = is an
implementation defect, that should be corrected in softwares! = The reality IS
that the duration of terrestrial days is constantly = changing, and we must
admit that a calendar day is not necessarily = exactly 24 hours (in fact is
NOT, and may even have never been 24 = hours exactly, i.e. 24*60*60 SI
seconds!)

If leap seconds have = been less used and heard of by implementers since some
years, it's = just because the deceleration of Earth rotation has slowed down
in = the recent period, meaning that there were less frequent insertions = of
leap seconds. This is ONLY temporary! In the next 10 years, we'll = need more
leap seconds because the Earth will restart decelerating at = higher rate,
meaning that more frequent leap seconds will be needed = (we don't have a very
long history of measurements of the Earth = rotation variations, but what is
now asserted, is that this rotation = speed is very irregular and depends on a
lot of factors, not all of = them endogen but caused for example by solar
activity, or by the = seasonal traversal of the Earth of "clouds" of dusts).

So please = don't use the excuse of BIOS and Windows limitations. Let's = admit
that a local time 23:59:60 or 23:59:61 is possible and not = necessarily equal
to 24:00:00. Let's accept that the terrestrial day = is not 24 hours exactly,
but let's keep our calendars synchronized = with Earth rotation. Trying to
convince everybody that a terrestrial = calendar day is now exactly 24 hours
will mean that you have changed = the definition of the second, a really bad
decision that will have = other severe impacts in physics for all other
measurements when = people won't remember that this variable second is
distinct from the = absolute and immutable physical = second!

= --Apple-Mail-20-1062540079-- From verdy_p@wanadoo.fr Wed Nov 28 13:22:32 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 28 Nov 2007 13:22:33 -0600 (CST) Received: from smtp21.orange.fr (smtp21.orange.fr [80.12.242.46]) by unicode.org (8.12.11/8.12.11) with ESMTP id lASJMWsC025257 for ; Wed, 28 Nov 2007 13:22:32 -0600 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2102.orange.fr (SMTP Server) with ESMTP id 5E26C1C000B7 for ; Wed, 28 Nov 2007 20:22:26 +0100 (CET) Received: from HARNON (unknown [90.50.99.181]) by mwinf2102.orange.fr (SMTP Server) with ESMTP id DB1D61C000B1; Wed, 28 Nov 2007 20:22:25 +0100 (CET) X-ME-UUID: 20071128192225897.DB1D61C000B1@mwinf2102.orange.fr Reply-To: From: "Philippe Verdy" To: "'Steven R. Loomis'" Cc: "'Christopher Fynn'" , References: <30b660a20711271759h7cc95ab5le94ef2239ddf97ce@mail.gmail.com> <00d401c83184$57ea0de0$0a01a8c0@HARNON> <474D66DF.7040505@gmx.net> <00ee01c831c3$fe5f2090$0a01a8c0@HARNON> Subject: RE: New version of tr35 Date: Wed, 28 Nov 2007 20:22:25 +0100 Organization: Ordinateur Personnel Message-ID: <010f01c831f4$025930c0$0a01a8c0@HARNON> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acgx17ceFECmye3YTtW1P6WieXPKcgAFkvUQ Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id lASJMWsC025257 X-archive-position: 289 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: verdy_p@wanadoo.fr Precedence: bulk X-list: cldr-users Steven R. Loomis wrote: > I understand the astrophysical reality, but the reality is also > that the time scale of 24*60*60 is what most people expect and > live in. (Although with daylight savings time, it is sometimes > 23 and sometimes 25 hours long.) That is what individuals and > organizations expect from locale data.  Yes but don't forget that application will compute these local times that people expect from some internal UTC reference managed in their computer. The locale data is supposed to be used also independently of the locale, that's why the CLDR makes a normative reference to UTC. But in that case, it has to support ALL the valid UTC datetime values, and so should not consider the specific case of local times that use daylight saving, but really what a UTC timestamp means. And for now, UTC means that physical seconds are used, not drifting seconds within some undefined continuous scale for which there is still NO standard to define how the clock speed is made continuous by varying the length of terrestrial-based seconds over time. Locale data should continue to work not only with normal humane time but also with time differences. When you speak about time differences, you need invariable seconds, i.e. the SI unit. Now, how will you compute the sum of an absolute date using a terrestrial based calendar that uses variable seconds and a difference of time in seconds? There's only one way to solve the problem: keep the second always absolute and fixed under the SI unit. Use another UNRELATED unit for terrestrial days and fractions of days. But don't call any fraction of day a "second". This is definitely not a second. Trying to mix them is exactly like trying to mix weights and volumes for measuring for example a known liquid: there's an *approximate* relation between those, but the exact ration between them can vary according to experimental conditions (notably temperature and pressure). You should think it the same way between UNRELATED units of days (terrestrial based and variable) and seconds (fixed length). You have another similar unit with years, which also vary because of the variation of year length in days (or independantly in seconds) over time. They are not measured using the same reference, so you can't add them. You should not mix them, because their relations are quite complex! (Note that the astronomic day and astronomic year are also defined arbitrarily as a fixed multiple of SI seconds, they are not the same units as our conventional and variable years and days...) I really hope that the proposal to redefine the second will fail, or that at least a workable normative model will allow converting continuous (variable) time scales into absolute time, without depending platform implementations, or on locale and local time adjustments (notably because this even varies between the BIOS that does not manage it, or the various OSes, or even between the various versions of Windows, or with local administration and tuning of local time servers...) This variability and unpredictability is the main reason why the UTC timescale succeeded because it was interoperable (even if it had to include leap seconds, that were still manageable and predictable months before they are added or subtracted). Now with the proposed continuous timescale, this predictability will be lost, and I expect even more problems with it than with leap seconds. With the existing UTC model, you just have to know that not all days have exactly 24 hours, some may be a bit shorter or longer, with a simple to compute difference of an exact small multiple of SI seconds. But this allows easy computing for differences of days, and between the dates of leap second adjustments, you still benefit of the fixed scale with a simple rule to adjust the differences by a fixed amount of seconds using a simple binary lookup in a sorted table of timestamp to UTC-TAI differences. I'm not sure that the document that you found will produce a simpler solution for the long term. It may even be worse and more complicate to manage! In fact it is already complicate to manage time differences caused by the many variations of orbital parameters of satellite systems. But if you have to manage this is now in a variable time scale, this will seriously complicate the computing formulas (in fact you'll constantly need to convert back and forth between the continuous variable scale and the absolute TAI reference just to make your physical formulas, used to compute the orbital parameters, work correctly!) For common applications where we just assume 24 imprecise hours per day, the UTC system is quite easy to adapt LOCALLY: just rescale the UTC days when a leap second occurs, and only these days. It's enough to compute local time and to avoid hours like 23:59:60.123 or 23:59:61.456 that are still not in the next UTC date. But for interchange and interoperability of timestamps, there's nothing better than UTC for now, **INCLUDING the support of leap seconds**. Note that in some countries, the leap seconds are not added or subtracted just before 00:00 UTC but later or sooner in the day, because they would otherwise fall in the middle of the day (when there are many ongoing economical transactions for example during the opening of daily stocks transactions; the order of execution of transactions is important to determine the price effectively payed, and you need sub-second precision to execute and match these orders by priority). This is not a theoretical problem but a very practical problem that has financial consequences because some orders won't be executable without a matching counter-offer; if timestamp is used as a reference and a proof for verifying the execution of sell/buy orders, it should be based on a standard reference timescale, and should not even depend on user locales! The same consideration is important within many computing transaction protocols that depend on correct ordering of absolute timestamps. So if some countries are adopting the "continuous" variable scale, and not others, let's expect new problems when converting local datetime across timezones or with UTC or TAI!