Improve and correct function definitions in Foundation types

Description

The current specification of arithmetic, comparison, and other such functions on the Foundation types is not generally correct UML. The functions need also to be expanded to more fully specify expected semantics for operators that may be used with all Foundation types, including the time types.

Activity

Show:
Matija Polajnar
March 25, 2020, 6:20 AM
  • valid_year: True if `y > 0`. should be True if `y >= 0`.

  • We really should get the ISO standard. Does it have upper bounds for fields? I think it shouldn’t. We discussed already the semantic difference between PT72H and P3D and I think it should be possible to express both values. (I’m relating to your valid_* functions.)

  • “or one or two days less where the following month is shorter” → “or possibly up to three days less where the following month is shorter”; possibly because this only applies when adding P1M to a date towards the end of the month, and up to three days when you fall from Jan 31st to Feb 28th.

  • I’m not sure I like the symbols ++ and -- because they have another meaning in common programming languages. But >>  also does, and the former are usually unary operators, so using them in a binary setting already gives a clue that it’s not the same thing, so we might just stick to those.

  • I don’t like the explanation. It IMHO unnecessarily wobbles around astronomy which is the one use-case that no medical expert nor IT expert will think of when reading a healthcare data format standard. It declares that integers are “internal machine representations” for data of this kind, which is only partly true (durations are not and can not be stored this way if you are ever to reconstruct the original and apply “nominal” calculations). Also it mentions P1M and P1Y as the volatile durations, when we know that P1D is also such. (Luckily, no one will probably ever care about leap seconds in the domain we’re dealing with.)

 

Thomas Beale
March 25, 2020, 10:57 AM

updates:

  • Valid_year - fixed

  • agree on getting the standard - I’ll have to do this a bit later, so there may be more adjustments to come from that.

  • 3 days case - fixed

  • I don’t really like ++ or -- (being an old C programmer), but at least they are related to the standard symbols + and - in an obvious way; my idea on >> and <<was based on the fast-forward /backward metaphor but I think would be unexpected in this context, when ‘much greater than’ is what many people will think of first.

  • explanation - I’ll try and improve.

 

Thomas Beale
March 26, 2020, 8:20 AM

The spec is now updated, according to the feedback, except for adjustments we might make from the latest version of the standard.

Matija Polajnar
March 26, 2020, 8:56 AM

I’m 99% ok with this so I’m just gonna give acceptance. Because you just had to go into details, now you have to fix them, though.

“in the case of adding a month to the date 31 Jan, the result will be 28 Feb, i.e. three less” → “in the case of adding a month to the date 31 Jan on a non-leap year, the result will be 28 Feb, i.e. three less”

Looking forward to acceptance from others so we get this over and done with.

Thomas Beale
March 26, 2020, 1:18 PM

Well caught. Probably other eagle eyes will catch a few other things.

Reporter

Thomas Beale

Raised By

Thomas Beale

Components

Affects versions

Configure