Storing dates earlier than 1st Jan 1970

[pankaj.puranik]

Hi

I came across this requirement where the user want to store Date of Birth in CMOD.
Obviously there would be many date that would be older than 1st Jan 1970.
The only option I can think of is to store it as a string and not date.

Any thoughts?

Thanks
Pankaj.

[Justin Derrick]

Upgrade to CMOD v9.x, and use the new database-based date field.  That should give you the ability to store dates between the years 0000 and 9999. 

-JD.

[Alessandro Perucchi]

Please.......................... tell the business that CMOD is not a DWH... that's an archive... it makes NO sense at all to have that information in CMOD.
It takes disk space for nothing.
That's also the role of the cmod admin to brake the business to make stupid choice...

The example of birthday is given in every cmod course in what to never do with an archive!!!

Probably you have implemented it now... and this is really sad...

[Justin Derrick]

Mark today on your calendar -- I actually disagree with Alessandro. 

Some of my biggest customers are health care companies.  And one of them has made a huge effort to get everything that is a 'form' into CMOD.  So if you show up at an Emergency Room in a department, they ask you for your name and date of birth on almost every form.  It's the same way police identify individuals, because it's extraordinarily close to being unique.

So, it only makes sense that you search for someone by their name, maybe their "health card" number, and the 'verification' information is their birthdate.  It's also not outrageous to use the date field as a second criteria for common names like "Susan Smith" and "Michael Lee".

Now, being a consultant that has to deal with this transition, I totally wish it had been done a decade ago, before the problem was so much bigger, and so much more complex.

-JD.

[Alessandro Perucchi]

Mark today on your calendar -- I actually disagree with Alessandro. 

Some of my biggest customers are health care companies.  And one of them has made a huge effort to get everything that is a 'form' into CMOD.  So if you show up at an Emergency Room in a department, they ask you for your name and date of birth on almost every form.  It's the same way police identify individuals, because it's extraordinarily close to being unique.

So, it only makes sense that you search for someone by their name, maybe their "health card" number, and the 'verification' information is their birthdate.  It's also not outrageous to use the date field as a second criteria for common names like "Susan Smith" and "Michael Lee".

Now, being a consultant that has to deal with this transition, I totally wish it had been done a decade ago, before the problem was so much bigger, and so much more complex.

 

Now that you give your example, I agree with you, such use case makes sense...
I have not worked with CMOD in the health industry, but mainly in the financial industry... and in that industry having the birthdate as a field makes no sense!!!

Thank you for your disagreement with me :-) I've learned something new today!!! :-) I know I will sleep like a baby tonight!!!

[ewirtz]

just an example. You want to find a customer with name 'Schmidt' (a lot of results). In such a case it helps to know the birthdate  to find the customers documents.

regards

Egon

[Alessandro Perucchi]

just an example. You want to find a customer with name 'Schmidt' (a lot of results). In such a case it helps to know the birthdate  to find the customers documents.

It really depends on the data model that was used for defining the field in the AG. At the moment, EXCEPT for the example provided by Justin, which seems appropriate in this use case... the birthdate is never needed, even in the case of 10000 "Schmid", then you use the customer ID, which is unique.
And if you use the birthdate for that kind of filtering, then something is not correct in my own opinion.

But again, that's my opinion, and others have their own view on what should be used or not on a data model for an AG.
And this is also OK :-)

[Ed_Arnold]

As Justin says, use the new date/time formats.

Reference this techdoc:

http://www-01.ibm.com/support/docview.wss?uid=swg27036188

The valid ranges for the Date/Time fields are as follows:


Date (old style)                   1970-01-01                         2058-12-31
Date                               0001-01-01                         9999-12-31

Date/Time (old style)              1970-01-01 00:00:00                2037-12-31 23:59:59
Date/Time                          0001-01-01 00:00:00                9999-12-31 23:59:59

Date/Time (TZ) (old style)         1970-01-01 00:00:00                2037-12-31 23:59:59
Date/Time (TZ)                     0001-01-01 00:00:00.000000         9999-12-31 23:59:59.999999

It won't work for the birth dates of the early Greeks but other than that you should be okay.   

Ed