From dherring at tentpost.com Sun Aug 1 14:36:20 2010 From: dherring at tentpost.com (Daniel Herring) Date: Sun, 1 Aug 2010 10:36:20 -0400 (EDT) Subject: [local-time-devel] arbitrary precision for fraction of a second In-Reply-To: References: Message-ID: 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 From thompdump at gmail.com Tue Aug 10 18:56:05 2010 From: thompdump at gmail.com (David A. Thompson) Date: Tue, 10 Aug 2010 11:56:05 -0700 Subject: [local-time-devel] arbitrary precision for fraction of a second In-Reply-To: References: Message-ID: <4C61A0C5.7070800@gmail.com> 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