That is true, but I think it would be good if it would find its way in the
RM, for two reasons
1) misusing the duration does not seem right, and I think the ISO string
representing a duration must change. That is, I know, a long way, so the
part before the 'T' should represent a calendar datatype,
Nothing restricts you to create a "data type pattern"/specialized cluster
that has exactly this semantics
El mar., 20 mar. 2018 23:34, A Verhees escribió:
> One last remark.
>
> There is in medical context need of a datatypes to express: "do this one
> time a month, for example on a specific dat
A Calendar datatype.
Op 20 mrt. 2018 23:33 schreef "A Verhees" :
> One last remark.
>
> There is in medical context need of a datatypes to express: "do this one
> time a month, for example on a specific date".
>
> But technically seen, this is not a duration, the maybe a need for another
> dataty
Nanoseconds are probably not needed many times in medical context, but they
are not in the way of using them as seconds or minutes.
Op 20 mrt. 2018 23:27 schreef "Diego Boscá" :
> We can revisit all the types we want, but we shouldn't forget that types
> will be used for medical data, and maybe w
One last remark.
There is in medical context need of a datatypes to express: "do this one
time a month, for example on a specific date".
But technically seen, this is not a duration, the maybe a need for another
datatype to express this.
Using the duration for this may be a handy shortcut in spe
We can revisit all the types we want, but we shouldn't forget that types
will be used for medical data, and maybe we don't really need nanosecond
precision.
El mar., 20 mar. 2018 23:09, A Verhees escribió:
> Now you say, you are right.
>
> The Java 8 duration is indeed diffrent, but you can stil
Now I come to think about it, I remember reading somewhere that conversion
durations to number of years or months is no longer desired because years
and months do not have always the same number of nanoseconds.
Of course conversions to days and weeks is easy, although they are also not
always the
Now you say, you are right.
The Java 8 duration is indeed diffrent, but you can still use the Joda
duration, or you can write your own duration class. In Golang the duration
class is also limited, it is build around nanoseconds, but I wrote my own
which is conform the OpenEhr specs, which was not
Yep, I know https://docs.oracle.com/javase/tutorial/datetime/iso/period.html
But this is not about anything Java specific, just giving an example why
Duration might not be good for an assumed type on the openEHR specs :)
On the other hand... (re)thinking: assumed types should not be considered
as
Java 8 has a Duration for hours, minutes and seconds, and Period for years,
months and days. Both implement a few interfaces with which you can abstract
them.
No idea why they chose this, it’s quite annoying to work with. You can
relatively easily implement your own variant of ChronoPeriof that
Thanks Thomas, will create the PR!
Also will double check if the same happens with other types, but I think
the only "odd" one that might not be correct to assume, is the Duration.
For instance, Java 8 added the Duration as a base type, but it only handles
day to seconds duration expressions, year
On 19/03/2018 22:25, Pablo Pazos wrote:
Hi Thomas, the definition of DV_DURATION is clear to me :)
The issue is on the 1.0.2 specs, I guess they used DV_DURATION in
C_DURATION because the referenced Duration class in C_DURATION was not
included on the specs. _This is the issue I'm pointing t
12 matches
Mail list logo
