oship-dev team mailing list archive
-
oship-dev team
-
Mailing list archive
-
Message #01635
Re: Last issues about date/time classes
-
To:
oship-dev@xxxxxxxxxxxxxxxxxxx
-
From:
Diego Manhães Pinheiro <me@xxxxxxxxxxxxxx>
-
Date:
Wed, 01 Dec 2010 21:10:53 -0200
-
In-reply-to:
<1291163047.7891.32.camel@mlhim-dell-laptop>
-
User-agent:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; pt-BR; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Em 30/11/10 22:24, Tim Cook escreveu:
> On Tue, 2010-11-30 at 21:49 -0200, Diego Manhães Pinheiro wrote:
>
>>> For example:
>>> a magnitude for 1953-10 would be the number of months 0001-01 to 1953-10
>> I think you missed an important point : magnitude must be a numeric
>> value as days (page 58 on data_types spec.) on DV_DATE objects and in
>> the seconds( page 59 ) for DV_TIME and DV_DATE_TIME (page 60), being
>> able to accept a partial or non-partial date/time format. So, How
>> should I proceed ?
>
> The openEHR specs are wrong or incomplete. You cannot do this without
> further guidance from the specs. So we deviate and document the
> differences. As I said, I think the rational thing to do is go with the
> smallest units available in a partial datetime. In any case where you
> might find data that is YYYY-MM-??:HH you cannot go with hours. Months
> is the small full unit you have.
Ok, but this case never will happen. The partial date/time only applies
to the fractional seconds to the year unit, following this order strictly.
>
> Does that make sense?
Yes, but I'm not totally convinced that partial date/time need to be
handled with different units. Anyway, this approach doesn't allow
compare a partial with a non-partial date/time without normalize the
numbers everytime that a object date/time is compared to other date/time
object.
>
>
>> Thanks. I didn't have any options, unless ask on the mailing list.
>> This topic is totally messed up both on the specification and on the
>> Internet.
>
> That is what happens when thoughtless people design standards :-)
>
>
> --Tim
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
iQEcBAEBAgAGBQJM9tX9AAoJEEfarWn4YOc8W8UH/3Cr1f4mIY9dF8k9K7UYaqGu
Qp1noqC4/AqYV4gYI8NJ6GzjozwlddxYl31mYd9NEnUWGNdT4S0tVBM42DfK9qoD
YyP1hPp3YA2B59pAHnnvjm2dusRdT7L48A2evZ5OWJX3U8L/4FbWSb/m8klHo0nR
8EXUt8a9SHBMHEnDqesWuK7+fUfWSoNZYGN6Db2WRtF+foOMAQ7bt+StZMF88Qsb
jRgCrpp3MlyWWfdshovsS2Jhzl421ozw7nD/guKZUEkrFL9zCE6WcqXnyIWEcfHh
ed/iXTuVOM+SKxlp7muTM6+0jrvrWTFC2+cMmHoOut5sXv6FUwYNoSQtL3q2kwc=
=pnc5
-----END PGP SIGNATURE-----
Follow ups
References