Issue 16680: Date-Time Issue - leap seconds (dtv-rtf) Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org) Nature: Uncategorized Issue Severity: Summary: (This comment came from the Architecture Board's review of the final submission.) This comment on page 16 [now Annex A.3 jarred somewhat: "These variations are accounted for by incorporating intercalary leap days and leap seconds into some calendar and timekeeping schemes. This specification chooses to support leap days, but not leap seconds, because leap days are significant to business while leap seconds are insignificant." It seems a bit arrogant to assert that "leap seconds are insignificant to business". If (for instance) your company's Telephone PABX were to crash at midnight on New Year's Eve because its software couldn't cope with leap-seconds, I suggest that would be "significant to business". Resolution: Revised Text: Actions taken: November 16, 2011: received issue April 1, 2013: transferred from FTF Discussion: End of Annotations:===== MG Issue No: 16680 Title: Leap Seconds Source: Andrew Watson . OMG . andrew@omg.org Summary: (This comment came from the Architecture Board's review of the final submission.) This comment on page 16 [now Annex A.3 jarred somewhat: "These variations are accounted for by incorporating intercalary leap days and leap seconds into some calendar and timekeeping schemes. This specification chooses to support leap days, but not leap seconds, because leap days are significant to business while leap seconds are insignificant." It seems a bit arrogant to assert that "leap seconds are insignificant to business". If (for instance) your company's Telephone PABX were to crash at midnight on New Year's Eve because its software couldn't cope with leap-seconds, I suggest that would be "significant to business". Resolution: To: date-time-ftf@omg.org Subject: Date-Time Issue 16680 - leap seconds X-KeepSent: F26DB92D:2F08CD9F-852579DB:0049EDFC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Mon, 9 Apr 2012 09:25:52 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/09/2012 09:25:53 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040913-6148-0000-0000-000004E733F2 Proposed resolution: -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research Date-Time Issue 16680 - leap seconds.doc Disposition: Resolved OMG Issue No: 16680 Title: Leap Seconds Source: Andrew Watson . OMG . andrew@omg.org Summary: (This comment came from the Architecture Board's review of the final submission.) This comment on page 16 [now Annex A.3 jarred somewhat: "These variations are accounted for by incorporating intercalary leap days and leap seconds into some calendar and timekeeping schemes. This specification chooses to support leap days, but not leap seconds, because leap days are significant to business while leap seconds are insignificant." It seems a bit arrogant to assert that "leap seconds are insignificant to business". If (for instance) your company's Telephone PABX were to crash at midnight on New Year's Eve because its software couldn't cope with leap-seconds, I suggest that would be "significant to business". Resolution: Revise the wording to indicate that leap seconds are "insignificant for many (but not all) businesses" and suggest the Internet Time calendar as an alternative. Revised Text: Change the last sentence of the 7th paragraph of clause 7.2 from: This specification chooses to support leap days, but not leap seconds, because leap days are significant to business while leap seconds are insignificant. to: For the Gregorian Calendar, this specification chooses to support leap days, but not leap seconds, because leap days are significant to business while leap seconds are insignificant for many (but not all) businesses. Internet Time (clause 9.5.7) may be used when leap seconds matter. Disposition: Resolved Date: Mon, 09 Apr 2012 14:43:52 +0000 From: "Chonoles, Michael J" Subject: RE: Ex: Date-Time Issue 16680 - leap seconds X-Originating-IP: [158.186.156.94] To: Mark H Linehan , "date-time-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "issue@omg.org" , "Calloni, Ben A" , "Watson, John" , "Hart, Laura E" , "Groder, Kenneth E (N-INtervise)" Thread-Topic: Ex: Date-Time Issue 16680 - leap seconds Thread-Index: AQHNFlYIyfPJytv8L06AGc/GclBQz5aSj24Q Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-04-09_03:2012-04-09,2012-04-09,1970-01-01 signatures=0 With this approach, (closing the issue of not-handling leap seconds as not relevant to many businesses) you.re really limiting the date-time spec to a small class of business applications, where a delta-time in seconds need not be exact and where clocks if off by several seconds are still ok. Official US time does include leap seconds, and changes in tax law, for example, would often occur at midnight, not a handful of seconds later. Remember these leap seconds could accumulate at the rate of 1-2 per year. There are many business transactions where the exact time of the transaction (e.g., even stock trades) can be significant if it changes the effective date of trade. This would also make it useless in many SysML applications. Lockheed Martin would certainly recommend voting against this resolution/standard. Michael From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, April 09, 2012 9:26 AM To: date-time-ftf@omg.org Subject: Ex: Date-Time Issue 16680 - leap seconds -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research Date-Time Issue 16680 - leap seconds1.doc To: "Chonoles, Michael J" Cc: "Calloni, Ben A" , "date-time-ftf@omg.org" , "issue@omg.org" , "Watson, John" , "Groder, Kenneth E (N-INtervise)" , "Hart, Laura E" , "sysml-rtf@omg.org" Subject: RE: Ex: Date-Time Issue 16680 - leap seconds X-KeepSent: F5F97CA3:6818B5C3-852579DB:0060F858; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Mon, 9 Apr 2012 13:41:55 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/09/2012 13:41:32, Serialize complete at 04/09/2012 13:41:32 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040917-1976-0000-0000-00000C30DB6F Hello, Michael -- We discussed this during our FTF phone call, just now -- and decided to add some support for leap seconds. Currently, DTV describes the Gregorian Calendar in terms of the UTC time scale. We will add definitions of the TAI time scale and leap seconds, will refer to the BIPM table of leap second adjustments, and will add text saying that leap seconds add discontinuities in the UTC time scale. These discontinuities affect use cases that are sensitive to leap seconds. Per ISO 80000-3, we will not change the definition of the 'day' time unit as a fixed 86 400 seconds. We are checking on the requirements of stock transactions, but are very doubtful that they are affected by leap seconds. We believe that markets open and close at particular times of day, and transactions settle at particular times of day. Such "times of day" are identified by the duration elapsed from midnight and thus are not affected by leap seconds. "Midnight" is defined in terms of UTC which is offset from TAI by the leap second table mentioned above. Thus, such transactions are basically insensitive to leap seconds. By the way, SysML applications that need to care about leap seconds should be using the TAI time scale, not UTC. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Chonoles, Michael J" To: Mark H Linehan/Watson/IBM@IBMUS, "date-time-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "issue@omg.org" , "Calloni, Ben A" , "Watson, John" , "Hart, Laura E" , "Groder, Kenneth E (N-INtervise)" Date: 04/09/2012 10:45 AM Subject: RE: Ex: Date-Time Issue 16680 - leap seconds -------------------------------------------------------------------------------- With this approach, (closing the issue of not-handling leap seconds as not relevant to many businesses) youâre really limiting the date-time spec to a small class of business applications, where a delta-time in seconds need not be exact and where clocks if off by several seconds are still ok. Official US time does include leap seconds, and changes in tax law, for example, would often occur at midnight, not a handful of seconds later. Remember these leap seconds could accumulate at the rate of 1-2 per year. There are many business transactions where the exact time of the transaction (e.g., even stock trades) can be significant if it changes the effective date of trade. This would also make it useless in many SysML applications. Lockheed Martin would certainly recommend voting against this resolution/standard. Michael From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, April 09, 2012 9:26 AM To: date-time-ftf@omg.org Subject: Ex: Date-Time Issue 16680 - leap seconds -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research [attachment "Date-Time Issue 16680 - leap seconds.doc" deleted by Mark H Linehan/Watson/IBM] Date: Mon, 09 Apr 2012 18:07:43 +0000 From: "Chonoles, Michael J" Subject: RE: Ex: RE: Ex: Date-Time Issue 16680 - leap seconds X-Originating-IP: [158.186.156.94] To: Mark H Linehan Cc: "Calloni, Ben A" , "date-time-ftf@omg.org" , "issue@omg.org" , "Watson, John" , "Groder, Kenneth E (N-INtervise)" , "Hart, Laura E" , "sysml-rtf@omg.org" Thread-Topic: Ex: RE: Ex: Date-Time Issue 16680 - leap seconds Thread-Index: AQHNFlYIyfPJytv8L06AGc/GclBQz5aSj24QgAB3EID//8LAwA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-04-09_03:2012-04-09,2012-04-09,1970-01-01 signatures=0 Great Thanks for the update. I.m still a bit concerned about determining the date of a trade that occurs around midnight, (for example a trade could occur at 86401 seconds after midnight and be in the previous day). And if you look at the time on w and w/o leap seconds after several years of drift, you could easily be 5 seconds off about what day it is. However, I appreciate your addressing the issue. Thanks Michael. From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, April 09, 2012 1:42 PM To: Chonoles, Michael J Cc: Calloni, Ben A; date-time-ftf@omg.org; issue@omg.org; Watson, John; Groder, Kenneth E (N-INtervise); Hart, Laura E; sysml-rtf@omg.org Subject: Ex: RE: Ex: Date-Time Issue 16680 - leap seconds Hello, Michael -- We discussed this during our FTF phone call, just now -- and decided to add some support for leap seconds. Currently, DTV describes the Gregorian Calendar in terms of the UTC time scale. We will add definitions of the TAI time scale and leap seconds, will refer to the BIPM table of leap second adjustments, and will add text saying that leap seconds add discontinuities in the UTC time scale. These discontinuities affect use cases that are sensitive to leap seconds. Per ISO 80000-3, we will not change the definition of the 'day' time unit as a fixed 86 400 seconds. We are checking on the requirements of stock transactions, but are very doubtful that they are affected by leap seconds. We believe that markets open and close at particular times of day, and transactions settle at particular times of day. Such "times of day" are identified by the duration elapsed from midnight and thus are not affected by leap seconds. "Midnight" is defined in terms of UTC which is offset from TAI by the leap second table mentioned above. Thus, such transactions are basically insensitive to leap seconds. By the way, SysML applications that need to care about leap seconds should be using the TAI time scale, not UTC. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Chonoles, Michael J" To: Mark H Linehan/Watson/IBM@IBMUS, "date-time-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "issue@omg.org" , "Calloni, Ben A" , "Watson, John" , "Hart, Laura E" , "Groder, Kenneth E (N-INtervise)" Date: 04/09/2012 10:45 AM Subject: RE: Ex: Date-Time Issue 16680 - leap seconds -------------------------------------------------------------------------------- With this approach, (closing the issue of not-handling leap seconds as not relevant to many businesses) you.re really limiting the date-time spec to a small class of business applications, where a delta-time in seconds need not be exact and where clocks if off by several seconds are still ok. Official US time does include leap seconds, and changes in tax law, for example, would often occur at midnight, not a handful of seconds later. Remember these leap seconds could accumulate at the rate of 1-2 per year. There are many business transactions where the exact time of the transaction (e.g., even stock trades) can be significant if it changes the effective date of trade. This would also make it useless in many SysML applications. Lockheed Martin would certainly recommend voting against this resolution/standard. Michael From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, April 09, 2012 9:26 AM To: date-time-ftf@omg.org Subject: Ex: Date-Time Issue 16680 - leap seconds -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research [attachment "Date-Time Issue 16680 - leap seconds.doc" deleted by Mark H Linehan/Watson/IBM] To: "Chonoles, Michael J" Cc: "Calloni, Ben A" , "date-time-ftf@omg.org" , "issue@omg.org" , "Watson, John" , "Groder, Kenneth E (N-INtervise)" , "Hart, Laura E" , "sysml-rtf@omg.org" Subject: RE: Ex: RE: Ex: Date-Time Issue 16680 - leap seconds X-KeepSent: B58D4F01:549D070F-852579DB:00646345; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Mon, 9 Apr 2012 14:16:34 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/09/2012 14:16:11, Serialize complete at 04/09/2012 14:16:11 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040918-3534-0000-0000-000007565C1F As I said, calculations that are sensitive to leap seconds should use the TAI time scale. We are checking with experts on the specific case of stock transactions, but we doubt they are sensitive to this issue. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Chonoles, Michael J" To: Mark H Linehan/Watson/IBM@IBMUS Cc: "Calloni, Ben A" , "date-time-ftf@omg.org" , "issue@omg.org" , "Watson, John" , "Groder, Kenneth E (N-INtervise)" , "Hart, Laura E" , "sysml-rtf@omg.org" Date: 04/09/2012 02:08 PM Subject: RE: Ex: RE: Ex: Date-Time Issue 16680 - leap seconds -------------------------------------------------------------------------------- Great Thanks for the update. Iâm still a bit concerned about determining the date of a trade that occurs around midnight, (for example a trade could occur at 86401 seconds after midnight and be in the previous day). And if you look at the time on w and w/o leap seconds after several years of drift, you could easily be 5 seconds off about what day it is. However, I appreciate your addressing the issue. Thanks Michael. From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, April 09, 2012 1:42 PM To: Chonoles, Michael J Cc: Calloni, Ben A; date-time-ftf@omg.org; issue@omg.org; Watson, John; Groder, Kenneth E (N-INtervise); Hart, Laura E; sysml-rtf@omg.org Subject: Ex: RE: Ex: Date-Time Issue 16680 - leap seconds Hello, Michael -- We discussed this during our FTF phone call, just now -- and decided to add some support for leap seconds. Currently, DTV describes the Gregorian Calendar in terms of the UTC time scale. We will add definitions of the TAI time scale and leap seconds, will refer to the BIPM table of leap second adjustments, and will add text saying that leap seconds add discontinuities in the UTC time scale. These discontinuities affect use cases that are sensitive to leap seconds. Per ISO 80000-3, we will not change the definition of the 'day' time unit as a fixed 86 400 seconds. We are checking on the requirements of stock transactions, but are very doubtful that they are affected by leap seconds. We believe that markets open and close at particular times of day, and transactions settle at particular times of day. Such "times of day" are identified by the duration elapsed from midnight and thus are not affected by leap seconds. "Midnight" is defined in terms of UTC which is offset from TAI by the leap second table mentioned above. Thus, such transactions are basically insensitive to leap seconds. By the way, SysML applications that need to care about leap seconds should be using the TAI time scale, not UTC. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Chonoles, Michael J" To: Mark H Linehan/Watson/IBM@IBMUS, "date-time-ftf@omg.org" , "sysml-rtf@omg.org" Cc: "issue@omg.org" , "Calloni, Ben A" , "Watson, John" , "Hart, Laura E" , "Groder, Kenneth E (N-INtervise)" Date: 04/09/2012 10:45 AM Subject: RE: Ex: Date-Time Issue 16680 - leap seconds -------------------------------------------------------------------------------- With this approach, (closing the issue of not-handling leap seconds as not relevant to many businesses) youâre really limiting the date-time spec to a small class of business applications, where a delta-time in seconds need not be exact and where clocks if off by several seconds are still ok. Official US time does include leap seconds, and changes in tax law, for example, would often occur at midnight, not a handful of seconds later. Remember these leap seconds could accumulate at the rate of 1-2 per year. There are many business transactions where the exact time of the transaction (e.g., even stock trades) can be significant if it changes the effective date of trade. This would also make it useless in many SysML applications. Lockheed Martin would certainly recommend voting against this resolution/standard. Michael From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, April 09, 2012 9:26 AM To: date-time-ftf@omg.org Subject: Ex: Date-Time Issue 16680 - leap seconds -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research [attachment "Date-Time Issue 16680 - leap seconds.doc" deleted by Mark H Linehan/Watson/IBM] To: date-time-ftf@omg.org Subject: Date-Time Issue 16680 - Leap Seconds X-KeepSent: CD5F781C:E585884E-852579EA:006EA4F2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Tue, 24 Apr 2012 21:21:37 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/24/2012 21:21:38 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12042501-5112-0000-0000-000007638168 Here is a new proposal for resolving this issue: -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research Date-Time Issue 16680 - leap seconds.doc Disposition: Resolved OMG Issue No: 16680 Title: Leap Seconds Source: Andrew Watson . OMG . andrew@omg.org Summary: (This comment came from the Architecture Board's review of the final submission.) This comment on page 16 [now Annex A.3 jarred somewhat: "These variations are accounted for by incorporating intercalary leap days and leap seconds into some calendar and timekeeping schemes. This specification chooses to support leap days, but not leap seconds, because leap days are significant to business while leap seconds are insignificant." It seems a bit arrogant to assert that "leap seconds are insignificant to business". If (for instance) your company's Telephone PABX were to crash at midnight on New Year's Eve because its software couldn't cope with leap-seconds, I suggest that would be "significant to business". Resolution: Currently, DTV describes the Gregorian Calendar in terms of the UTC time scale. To provide some support for leap seconds, add definitions of the TAI time scale and leap seconds, and add text saying that leap seconds add discontinuities in the UTC time scale. These discontinuities affect use cases that are sensitive to leap seconds. Per ISO 80000-3, the definition of the 'day' time unit remains as a fixed 86 400 seconds. Revised Text: CHANGE the 7th paragraph of clause 7.2 from: It is noted that, except for the second, none of the units of time are of exactly the same duration. This variation arises because the periods of rotation and revolution of the Earth and Moon are incommensurable and irregular, significantly complicating the task of timekeeping. These variations are accounted for by incorporating intercalary leap days and leap seconds into some calendar and timekeeping schemes. This specification chooses to support leap days, but not leap seconds, because leap days are significant to business while leap seconds are insignificant. to: Timekeeping is significantly complicated by the incommensurable and irregular periods of rotation and revolution of the Earth and Moon. These variations are accounted for at the granularity of 'day' by incorporating intercalary leap days in the Gregorian Calendar, and at the granularity of 'second' by incorporating intercalary leap seconds in UTC. Businesses sensitive at the granularity of 'second' should use TAI, which is independent of leap seconds. In clause 9.1, REPLACE the Note under 'precise time unit' which reads: Note: [ISO 8601] defines .hour. and .minute. precisely. Leap seconds are added or deleted from a calendar day, not an hour of day or minute of hour, even though a leap second is designated as 23:59:60 of the day in which it is added. However, this document does not model leap seconds. with: Note: [SI] defines 'hour', 'minute', and 'day' precisely. Although not addressed by [SI], 'week' also meets the definition of 'precise time unit'. Leap seconds are considered to introduce discontinuities in UTC, rather than variation in the definition of 'day'. In clause 9.1, DELETE the Note under 'nominal time unit' which reads: Note: This specification ignores leap seconds because they are not relevant to most business affairs. In clause 9.1.2, REPLACE the first three Notes under 'day', which read: Note: For business purposes, this document treats .day. as a precise time unit, even though the duration of a calendar day varies due to leap seconds and due to discontinuities when a locality switches between standard time and daylight time. Domain vocabularies may define a nominal time unit that takes such variations into account for scientific, engineering, or academic purposes. Note: In UTC, a leap second may be added or subtracted about every 18 months, on June 30 or December 31, as determined by the International Earth Rotation and Reference Systems Service (IERS). (There have been no subtractions to date, as the rotation of the Earth is slowing.) Leap seconds are used to keep UTC aligned with ephemeris time to within one second, and can only be predicted about six months in advance, because of irregularities in the Earth.s rotation. Note: Some time standards do not use leap seconds, notably GPS time and International Atomic Time (TAI), on which UTC is based. with: Note: 'Day' is defined in [SI] as 86 400 seconds. Leap seconds are intercalary seconds of day that are inserted as needed into UTC. Leap seconds do not affect the definition of 'day'. In clause 9.5.2, replace Figure 9.9 with this (which adds 'leap second'): (figure to be added) In clause 9.5.2, ADD a new glossary entry under 'second of day': leap second Definition: second of day that is used to adjust UTC to ensure appropriate agreement with the rotation of the Earth Dictionary Basis: ISO 8601 (2.2.2, 'leap second') Note: Leap seconds are added or deleted at 23:59:59 on specific calendar days of UTC. These intercalary seconds of day adjust midnight of the next calendar day to match Earth's rotation. The International Earth Rotation and Reference Systems Service [IERS] announces leap seconds whenever the difference between UTC and the Earth's rotation exceeds 0.6 seconds. Note: As of 2012, there is a proposal to drop the 'leap second' concept. This proposal will be formally considered at the World Radio Conference in 2015. In clause 9.5.4, replace Figure 9.11 with this (which adds 'TAI'): (figure to be added) In clause 9.5.4, Time Zones, REPLACE the final two sentences of the last Note under "UTC", which read: This specification ignores leap seconds; day is considered to be a precise time unit of 86 400 seconds, not a nominal time unit of {86 400 days, 86 401 days}. Applications that entail leap seconds need to extend this specification to include them. with these sentences: The leap second adjustments make UTC a discontinous time scale. Businesses that are sensitive to the leap second discontinuities should use TAI instead. In clause 9.5.4, ADD a new glossary entry immediately after the entry for "UTC": TAI Synonym: Temps Atomic International Synonym: International Atomic Time Definition: time scale that is defined in a geocentric reference frame with the SI second as realized on the rotating geoid as the scale unit Source: SI Note: SI cites the "declaration of the CCDS, BIPM Com. Cons. Dé Seconde, 1980, 9, S 15 and Metrologia, 1981, 17, 70". Necessity: The granularity of TAI Scale is second. Note: TAI is a continuous time scale of seconds, maintained by the Bureau International des Poid et Mesures (BIPM) as the average of over 200 hundred atomic clocks located in over 50 national laboratories. Businesses that are sensitive to the discontinuities of UTC should instead use TAI. ADD a new entry in alphabetical order to Annex B . References: IERS International Earth Rotation and Reference Service. See www.iers.org. Disposition: Resolved To: date-time-ftf@omg.org Subject: Date-Time Issue 16680 - Leap Seconds X-KeepSent: 8A96D45E:1DE88200-85257A17:006D72A2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Mark H Linehan Date: Fri, 8 Jun 2012 15:57:44 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 06/08/2012 15:57:44 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12060819-8974-0000-0000-000009E36E4D We discussed this back on April 30, pending the UML diagrams. Here's the final draft including those diagrams. Unless I hear otherwise, I believe this is ready for ballot. -------------------------------- Mark H. Linehan STSM, IBM Research Date-Time Issue 16680 - leap seconds.doc Disposition: Resolved OMG Issue No: 16680 Title: Leap Seconds Source: Andrew Watson . OMG . andrew@omg.org Summary: (This comment came from the Architecture Board's review of the final submission.) This comment on page 16 [now Annex A.3 jarred somewhat: "These variations are accounted for by incorporating intercalary leap days and leap seconds into some calendar and timekeeping schemes. This specification chooses to support leap days, but not leap seconds, because leap days are significant to business while leap seconds are insignificant." It seems a bit arrogant to assert that "leap seconds are insignificant to business". If (for instance) your company's Telephone PABX were to crash at midnight on New Year's Eve because its software couldn't cope with leap-seconds, I suggest that would be "significant to business". Resolution: Currently, the Date-Time Vocabulary describes the Gregorian Calendar in terms of the UTC time scale. To support leap seconds, add definitions of the TAI time scale and leap seconds, and add text saying that leap seconds add discontinuities in the UTC time scale. These discontinuities affect use cases that are sensitive to leap seconds. Per ISO 80000-3, the definition of the 'day' time unit remains as a fixed 86 400 seconds. Revised Text: CHANGE the 7th paragraph of clause 7.2 from: It is noted that, except for the second, none of the units of time are of exactly the same duration. This variation arises because the periods of rotation and revolution of the Earth and Moon are incommensurable and irregular, significantly complicating the task of timekeeping. These variations are accounted for by incorporating intercalary leap days and leap seconds into some calendar and timekeeping schemes. This specification chooses to support leap days, but not leap seconds, because leap days are significant to business while leap seconds are insignificant. to: Timekeeping is significantly complicated by the incommensurable and irregular periods of rotation and revolution of the Earth and Moon. These variations are accounted for at the granularity of 'day' by incorporating intercalary leap days in the Gregorian Calendar, and at the granularity of 'second' by incorporating intercalary leap seconds in UTC. Businesses sensitive to elapsed 'seconds' should use TAI, while those that are concerned with calendar alignment may prefer UTC. In clause 9.1, REPLACE the Note under 'precise time unit' which reads: Note: [ISO 8601] defines .hour. and .minute. precisely. Leap seconds are added or deleted from a calendar day, not an hour of day or minute of hour, even though a leap second is designated as 23:59:60 of the day in which it is added. However, this document does not model leap seconds. with: Note: [SI] defines 'hour', 'minute', and 'day' precisely. Although not addressed by [SI], 'week' also meets the definition of 'precise time unit'. Leap seconds are considered to introduce discontinuities in UTC, rather than variation in the definition of 'day'. In clause 9.1, DELETE the Note under 'nominal time unit' which reads: Note: This specification ignores leap seconds because they are not relevant to most business affairs. In clause 9.1.2, REPLACE the first three Notes under 'day', which read: Note: For business purposes, this document treats .day. as a precise time unit, even though the duration of a calendar day varies due to leap seconds and due to discontinuities when a locality switches between standard time and daylight time. Domain vocabularies may define a nominal time unit that takes such variations into account for scientific, engineering, or academic purposes. Note: In UTC, a leap second may be added or subtracted about every 18 months, on June 30 or December 31, as determined by the International Earth Rotation and Reference Systems Service (IERS). (There have been no subtractions to date, as the rotation of the Earth is slowing.) Leap seconds are used to keep UTC aligned with ephemeris time to within one second, and can only be predicted about six months in advance, because of irregularities in the Earth.s rotation. Note: Some time standards do not use leap seconds, notably GPS time and International Atomic Time (TAI), on which UTC is based. with: Note: 'Day' is defined in [SI] as 86 400 seconds. Leap seconds are intercalary seconds of day that are inserted as needed into UTC. Leap seconds do not affect the definition of 'day'. Note: The duration of a calendar day is not necessarily 1 day, due to leap seconds and discontinuities when a locality switches between standard time and daylight time. In clause 9.5.2, replace Figure 9.9 with this (which adds 'leap second'): In clause 9.5.2, ADD a new glossary entry under 'second of day': leap second Definition: second of day that is used to adjust UTC to ensure appropriate agreement with the rotation of the Earth Dictionary Basis: ISO 8601 (2.2.2, 'leap second') Note: Leap seconds are added or deleted at 23:59:59 on specific calendar days of UTC. These intercalary seconds of day adjust midnight of the next calendar day to match Earth's rotation. The International Earth Rotation and Reference Systems Service [IERS] announces leap seconds whenever the difference between UTC and the Earth's rotation exceeds 0.6 seconds. Note: As of 2012, there is a proposal to drop the 'leap second' concept. This proposal will be formally considered at the World Radio Conference in 2015. In clause 9.5.4, replace Figure 9.11 with this (which adds 'TAI'): In clause 9.5.4, Time Zones, REPLACE the final two sentences of the last Note under "UTC", which read: This specification ignores leap seconds; day is considered to be a precise time unit of 86 400 seconds, not a nominal time unit of {86 400 days, 86 401 days}. Applications that entail leap seconds need to extend this specification to include them. with these sentences: The leap second adjustments make UTC a discontinuous time scale. Businesses that are sensitive to elapsed seconds of day may prefer to use TAI instead. In clause 9.5.4, ADD a new glossary entry immediately after the entry for "UTC": TAI Synonym: Temps Atomique International Synonym: International Atomic Time Definition: time scale that is defined in a geocentric reference frame with the SI second as realized on the rotating geoid as the scale unit Source: SI Note: SI cites the "declaration of the CCDS, BIPM Com. Cons. Dé Seconde, 1980, 9, S 15 and Metrologia, 1981, 17, 70". Necessity: The granularity of the TAI Scale is 'second'. Note: TAI is a continuous time scale of seconds, maintained by the Bureau international des poids et mesures (BIPM) as the average of over 200 hundred atomic clocks located in over 50 national laboratories. Businesses that are sensitive to the discontinuities of UTC should instead use TAI. ADD a new entry in alphabetical order to Annex B . References: IERS International Earth Rotation and Reference Service. See www.iers.org. Disposition: Resolved Date: Fri, 08 Jun 2012 20:57:29 +0000 From: "Chonoles, Michael J" Subject: RE: Ex: Date-Time Issue 16680 - Leap Seconds X-Originating-IP: [158.186.156.94] To: Mark H Linehan , "date-time-ftf@omg.org" Thread-Topic: Ex: Date-Time Issue 16680 - Leap Seconds Thread-Index: AQHNRbFRJEDRpf2iA0uKZ4QKlSYOjpbw5pgw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580,1.0.260,0.0.0000 definitions=2012-06-08_08:2012-05-21,2012-06-08,1970-01-01 signatures=0 Looks good. Except, unfortunately, I.m having difficultly reading the entire document. I also wonder if you need anywhere to define the range of seconds in a day or of the time of day On days with an added leap second, the time can be 23:59:60 And the total number of seconds in a day can be 86401 If there is no impact from this, you.re ok. Thanks Michael From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Friday, June 08, 2012 3:58 PM To: date-time-ftf@omg.org Subject: Ex: Date-Time Issue 16680 - Leap Seconds the UML diagrams. Here's the final draft including those diagrams. Unless I hear otherwise, I believe this is ready for ballot. -------------------------------- Mark H. Linehan STSM, IBM Research Date: Fri, 8 Jun 2012 18:09:25 -0400 From: Ed Barkmeyer Reply-To: Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "Chonoles, Michael J" CC: Stan Hendryx , "date-time-ftf@omg.org" Subject: Re: Ex: Date-Time Issue 16680 - Leap Seconds X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q58M9TsQ006489 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1339798174.07216@jajtNiVUlkom+wi5zg1OdQ X-Spam-Status: No Chonoles, Michael J wrote: Looks good. Except, unfortunately, I.m having difficultly reading the entire document. Hmm. the beta-1 spec is dtc/2012-01-02. I also wonder if you need anywhere to define the range of seconds in a day or of the time of day On days with an added leap second, the time can be 23:59:60 And the total number of seconds in a day can be 86401 You point out an inconsistency. DTV says that the 'day of seconds scale' has 86400 second-of-day time points. It should have 86401. The last time point is the leap second time point, which corresponds to very few actual time intervals. Similarly, the second-of-minute time scale has 61 time points, although the 61st corresponds only to leap seconds. That the scale has a 61st time point does not mean that every instance of minute-of-hour has a 61st second. (In a similar way, the month of days has 31 time points, but not every month time interval is 31 day time intervals.) Note also that the time coordinate for a leap second is also affected by time zones and scale offsets. The leap second is 23:59:60 UTC, but it is 19:59:60 EDT. The total number of seconds in a SI 'day' is 86400 always. The total number of seconds in a 'calendar day' can be 86401, and that is what 'second-of-day' time points are about. There is a further discrepancy in that the UML model in Figure 9.9 says that minute-of-day is a sequence of 59..61 second-of-day time points. It isn't. It can be converted to such a sequence, but it is not one, and the same is true of hour-of-day being 60 minute-of-day time points. So the UML model should be fixed (and silent on this issue). Upshot: This issue resolution still needs work. Thanks, -Ed If there is no impact from this, you.re ok. Thanks Michael *From:* Mark H Linehan [mailto:mlinehan@us.ibm.com] *Sent:* Friday, June 08, 2012 3:58 PM *To:* date-time-ftf@omg.org *Subject:* Ex: Date-Time Issue 16680 - Leap Seconds the UML diagrams. Here's the final draft including those diagrams. Unless I hear otherwise, I believe this is ready for ballot. -------------------------------- Mark H. Linehan STSM, IBM Research -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority."