DR 12-0004 - SML: Decimal Precision of ISO 8601 Times

John Haug johnhaug at exchange.microsoft.com
Thu Apr 26 15:36:24 CEST 2012


We looked at this on the conference call and it seemed reasonable.  Gareth, can you take a look at the attachment in the message below and let us know what you think?

From: John Haug [mailto:johnhaug at exchange.microsoft.com]
Sent: Friday, March 30, 2012 4:25 PM
To: SC34
Subject: DR 12-0004 - SML: Decimal Precision of ISO 8601 Times

Hi all -
I finally got my hands on ISO/IEC 9075 and looked up how it handles time precision.  In short, there seem to be some context-specific concerns, but in general it merely provides for appending "(#)" to the decimal time value to indicate the number of digits for fractional second precision.  I didn't see whether that is always the same as the number of digits that actually appear after the decimal point for a given time value, which would seem less than useful.  I didn't investigate this angle further as it seemed ancillary to our DR.

To document what we looked up and discussed during the teleconference, here are examples of the number of decimal digits for fractional time support for most typical cases/datatypes in a few of the larger databases:

*         SQL Server 2012 Transact-SQL:  0-7 digits (default: 7)

*         Oracle 9i, 10g, 11g: 0-9 digits (default: 6)

*         MySQL 5: 0-6 digits, but discarded on storage (i.e., ephemeral/runtime use only)

*         PostgreSQL 8, 9: 0-6 digits (default: ?)

I'm attaching as tracked changes draft 1 of the changes we discussed making (should, guidance/rationale).  Given that 6+ digits is typical in the list above, I wonder if we ought to change the recommended number of digits from 3 to 6?  I'm also still not certain whether "with no more than X decimal places" or "with no fewer than X decimal places" or simply "with X decimal places" is the best choice.  Any thoughts on that?

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20120426/8f43cea2/attachment.htm>


More information about the sc34wg4 mailing list