Hi Tom, I've been experimenting to save to Ehrscape and it seems the implementation is truncating (not rounding off) beyond 3digits. So whatever I include after 3rd digit is not saved.
"encounter/body_weight:0/any_event:1/time": "2016-02-01T01:04:09.907123Z" > I get: "encounter/body_weight:0/any_event:1/time": "2016-02-01T01:04:09.907Z" To be honest the spec as it reads now seems ambiguous with 3 digits. Cheers, -koray From: openEHR-technical [mailto:[email protected]] On Behalf Of Thomas Beale Sent: Wednesday, 3 February 2016 12:21 a.m. To: [email protected] Subject: Re: Representing microseconds in DateTime I don't think there is any assumption that [,sss] means there are no microseconds. The field is just called 'fractional_second' and it's a Real (i.e. a float). We just used 'sss' as an arbitrary indicator of fractional seconds (how many 's' do you want ;-) - thomas On 02/02/2016 09:51, Koray Atalag wrote: Hi, I have a requirement to capture timeseries data which happens at 250 microseconds - that is 0.000250 seconds. While many programming languages, and the ISO8601 spec, supports this openEHR RM<http://www.openehr.org/releases/RM/latest/docs/support/support.html#_iso8601_time_class> seems to be constrained to milliseconds: hh:mm:ss[,sss][Z | ±hh[mm]] Any particular reason we dump microseconds? If not can we add this capability - I think it won't break any existing code (I hope!) Cheers,
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
