[local-time-devel] arbitrary precision for fraction of a second

[David A. Thompson]

On 08/01/2010 07:36 AM, Daniel Herring wrote:
> On Wed, 14 Jul 2010, david thompson wrote:
> 
>> My understanding is that the ISO 8601 spec permits an arbitrary number
>> of digits following the decimal point when a decimal fraction of an
>> hour, minute, or second is specified.
>>
>> This works fine:
>>>  (LOCAL-TIME:PARSE-TIMESTRING "2010-07-12T16:07:08.123742200")
>> @2010-07-12T09:07:08.123742-07:00
>>
>> This doesn't:
>>> (LOCAL-TIME:PARSE-TIMESTRING "2010-07-12T16:07:08.1237422004")
>>
>> Is the constraint on the number of digits LOCAL-TIME permits following
>> the decimal character specified in the LOCAL-TIME documentation?
> 
> PARSE-TIMESTRING is layered on top of %SPLIT-TIMESTRING, which has the
> following docstring.
> "Based on http://www.ietf.org/rfc/rfc3339.txt including the function
> names used. Returns (values year month day hour minute second nsec
> offset-hour offset-minute). On parsing failure, signals
> INVALID-TIMESTRING if FAIL-ON-ERROR is NIL, otherwise returns NIL."
> 
> Does that RFC make any restrictions on the precision?
> 
> Anyway, the issue you are hitting is that TIME-SECOND within
> %SPLIT-TIMESTRING is reading 1237422004 as an integer and failing to
> convert it into an integer number of nanoseconds.  Instead of silently
> truncating the 4, the function signals an error.
> 
> Later,
> Daniel

As far as I can see, there isn't a restriction on the precision. Section
5.6 of RFC3339 seems to describe how ISO 8601 should be used to specify
dates. The 'time-secfrac' specification ( time-secfrac    = "." 1*DIGIT
) doesn't limit the number of digits which can be used to specify a
fraction of a second.

Obviously, most implementations will encounter a practical limit with
respect to the number of digits which are considered or allowed. Perhaps
at least some aspect of this should be explicit in the LOCAL-TIME
documentation (e.g., either an indication of silent truncation or an
indication of the permissible precision)?

- Alan