This project is read-only.

OjbectYr versus ObjectDt

Topics: Resources
Mar 5, 2016 at 6:34 PM
The issue of Year vs Date has always been an issue with vendors, carriers, and messages. I propose we completely do away with both.

If we adopt a field, that is yyyymmdd we get the following:

Roof Year 1999 = 19990000 : indicates only year is known or wanted
Roof Date 01/01/1999 = 19990101 : gives both year and date

We can call it RoofYD, meaning YearDate, and do this for all objects and once and for all get rid of the confusion over this issue.
Apr 7, 2016 at 8:26 PM
I see a few problems with the proposal:
  1. The usage of the xsd:date format in Date is already established.
  2. The proposal does not take into account the capability that xsd:date currently provides, namely, [-]CCYY-MM-DD[Z|(+|-)hh:mm]. Valid values include: 2001-10-26, 2001-10-26+02:00, 2001-10-26Z, 2001-10-26+00:00, -2001-10-26, or -20000-04-01. The W3C XML Schema indicates that a date is a "one-day-long, non-periodic instance ... independent of how many hours this day has." Some days don't last exactly 24 hours because of leap seconds.
  3. Removing the permissable punctuation characters (-,+ and :) would break all existing implementations that currently use them - and ALL currently use the "-" at a minimum.
The proposal provides date fuzziness and flexibility, in that one can provide a year, a year/month or a year/month/day. The current Date definition is a union between xsd:date, xsd:gYear and xsd:gYrMon - which accomplishes the same thing. There does not appear to be any benefit in adopting a different type of fuzzy date - the underlying business problem that needs to be solved is identifying which XML dates require strict CCYY-MM-DD dates.

Finally, it would be difficult to persuade the voters to add entirely new elements to the standard to support another fuzzy date format.

What we need is a list of elements that require firm, formal year-month-date values. ExpirationDt. EffectiveDt. Systems require the fully-qualified date, not a fuzzy value.
Apr 7, 2016 at 9:38 PM

That is a very qualified and informative explanation. Thank you.

I am remembering the past discussions on roofYr vs roofDt vs fuzzy.

We have removed all of these in our system with the yyyymmdd format. It makes it very easy to do things like add a year, yyyymmdd + 1000 (with leap year check), index, graph node processing, etc. Almost everything is stored and processed this way that doesn't require a hhmmss detail.

I would disagree on identifying which dates should require strict CCYY-MM-DD dates. Reason being, that you are now forcing business rules on what should be a business neutral architecture. The version of fuzzy date I proposed, allows everyone to do their own thing.

I agree it would be difficult that it would be difficult to add another format. We will just convert to YD and back.

Its very fuzzy... sorry I couldn't resist.

Thank you again James.