Re: Representing microseconds in DateTime

[Thomas Beale]

Well, we can change the spec if people find it confusing, but as far as 
I can see, it doesn't say anything about milliseconds or limiting 
fractional seconds to 3 places.


But if you want to propose a wording change, feel free to raise a PR, we 
can address it in the next minor release.


- thomas

On 02/02/2016 11:42, Koray Atalag wrote:


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 3^rd 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.



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: [FORGED] Re: [FORGED] Re: Representing microseconds in DateTime

[Koray Atalag]

And I just noted, Ocean's Archetype Editor does allow for microseconds but when 
you select and save it cannot save it. So it is a bug.

It looks definitely a deficiency of the openEHR RM.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: Tuesday, 2 February 2016 11:18 p.m.
To: For openEHR technical discussions
Subject: [FORGED] Re: [FORGED] Re: Representing microseconds in DateTime

On 02-02-16 11:07, Koray Atalag wrote:
Hi Bert, I was saying ISO8601 do support this - it is openEHR that constrains 
to milliseconds.

You are right, you do say that. I don't know if your code supports this, 
because the ISO-time-string will be converted to a Time-class and must have the 
same value when converted back.

The Java 8 LocalTime class supports until 9 decimals.




In my case it is action potential measurement from myocytes

Sounds interesting, I asked because it is rare to measure microseconds in 
medical applications.

regards
Bert
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: [FORGED] Re: Representing microseconds in DateTime

[Koray Atalag]

Hi Bert, I was saying ISO8601 do support this - it is openEHR that constrains 
to milliseconds.

In my case it is action potential measurement from myocytes

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: Tuesday, 2 February 2016 10:59 p.m.
To: openehr-technical@lists.openehr.org
Subject: [FORGED] Re: Representing microseconds in DateTime

Just for the record, which medical requirement makes measuring micro-seconds 
necessary?

By the way, ISO allows one or more digits to represent a decimal fraction of a 
second.

I don't have the original standard at hand, but Wikipedia says:
https://en.wikipedia.org/wiki/ISO_8601
There is no limit on the number of decimal places for the decimal fraction.

Bert




On 02-02-16 10: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,

-koray





___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Representing microseconds in DateTime

[Diego Boscá]

Probably we should be faithful to ISO8601 and allow this, I don't see
any reason why we shouldn't.

2016-02-02 10:51 GMT+01:00 Koray Atalag :
> 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 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,
>
>
>
> -koray
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Representing microseconds in DateTime

[Koray Atalag]

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
 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,

-koray

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Representing microseconds in DateTime

[Koray Atalag]

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:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Wednesday, 3 February 2016 12:21 a.m.
To: openehr-technical@lists.openehr.org
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
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Representing microseconds in DateTime

[Thomas Beale]

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 
 
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
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: [FORGED] Re: [FORGED] Re: Representing microseconds in DateTime

[Koray Atalag]

Hi Bert, yes it is an extreme case - most clinical measurements will not go in 
this range.

Python's DateTime library <https://docs.python.org/2/library/datetime.html>  
(which I'm using at the moment) supports 6 digits after decimal point which 
gives resolution of 1 microseconds.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: Tuesday, 2 February 2016 11:18 p.m.
To: For openEHR technical discussions
Subject: [FORGED] Re: [FORGED] Re: Representing microseconds in DateTime

On 02-02-16 11:07, Koray Atalag wrote:
Hi Bert, I was saying ISO8601 do support this - it is openEHR that constrains 
to milliseconds.

You are right, you do say that. I don't know if your code supports this, 
because the ISO-time-string will be converted to a Time-class and must have the 
same value when converted back.

The Java 8 LocalTime class supports until 9 decimals.




In my case it is action potential measurement from myocytes

Sounds interesting, I asked because it is rare to measure microseconds in 
medical applications.

regards
Bert
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [FORGED] Re: Representing microseconds in DateTime

[Bert Verhees]

On 02-02-16 11:07, Koray Atalag wrote:


Hi Bert, I was saying ISO8601 do support this – it is openEHR that 
constrains to milliseconds.




You are right, you do say that. I don't know if your code supports this, 
because the ISO-time-string will be converted to a Time-class and must 
have the same value when converted back.


The Java 8 LocalTime class supports until 9 decimals.



In my case it is action potential measurement from myocytes



Sounds interesting, I asked because it is rare to measure microseconds 
in medical applications.


regards
Bert
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Representing microseconds in DateTime

[Bert Verhees]

Just for the record, which medical requirement makes measuring 
micro-seconds necessary?


By the way, ISO allows one or more digits to represent a decimal 
fraction of a second.


I don't have the original standard at hand, but Wikipedia says:
https://en.wikipedia.org/wiki/ISO_8601
There is no limit on the number of decimal places for the decimal fraction.

Bert




On 02-02-16 10: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 
 
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,

-koray



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org