Yes, you're right about this being a floating point issue.  I guess I 
wasn't clear enough that this was already understood.  I'd have responded 
earlier the response somehow missed my mailbox.

My question is rather whether there is a work around for correctly 
displaying POSIXct values as character strings without modifying 
print.POSIXct().  I've not been able to hit on one yet, though this seems 
like a very simple problem to get past.

cur

> Jim Holtman wrote, on Thu, 19 Jan 2012 20:51:53
>This is basically FAQ 7.31. WIth floating point number, you have about 15 

> digits of significance, so if you look at the value:
>
>> as.numeric(as.POSIXct('2010-06-03 9:03:58.324'))
>> [1] 1275581038.3239998817
> 
>when you get down to the milliseconds, this is about as much accuracy as 
> you will get based on using POSIXct with dates around this century.. 
>  ...

>On Thu, Jan 19, 2012 at 3:57 PM, Curt Seeliger 
<Seeliger.Curt_at_epamail.epa.gov> wrote:
>> First, the reproducable example, showing how converting from character 
to
>> POSIXct to character changes the milliseconds in the first time stamp
>> though not in the second:
>>
>> as.POSIXct('2010-06-03 9:03:58.324')
>> [1] "2010-06-03 09:03:58.323 PDT"
>>
>> as.POSIXct('2010-06-03 9:03:58.325')
>> [1] "2010-06-03 09:03:58.325 PDT"
>>
>> This seems to be due to truncation of the numeric value of the POSIX
>> object during conversion to character:
>>
>> as.numeric(as.POSIXct('2010-06-03 9:03:58.324'))
>> [1] 1275581038.3239998817
>>
>> Neither format() nor round() seem to be of assistance here.  Anyone got 
a
>> solution?
>> ...
>
-- 
Curt Seeliger, Data Ranger
Raytheon Information Services - Contractor to ORD
seeliger.curt@epa.gov
541/754-4638

	[[alternative HTML version deleted]]

