- This topic has 2 replies, 1 voice, and was last updated 14 years, 9 months ago by
.
-
Topic
-
I just found out the convert_date has been deprecated. We are using Cloverleaf 5.6 (it worked in 5.2 from which we are migrating).
Right now the impact is that the command functions but does not provide missing date or time information.
For example to convert the current date time to a time-stamp format (CCYYMMDDHHMMSS) with convert_date one would code:
convert_date dt “” ts 12.
The null above is the date/time to be converted. If it is null, then the data type for the date/time to be formatted (the dt above) is ignored and instead the current date/time is used as the source date/time.
In 5.2 the above worked properly.
In 5.6 only CCYY was returned.
Also there was the potential with convert_date to acquire the missing time portion from the current time.
For example convert_date dt “20091231” ts 12 would provide:
20091231135500 (assuming the current time at execution was 13:00:00).
In 5.6, the time is not provided.
The replacement suggested is to us the Tcl clock command. However, the clock command is not knowledgeable of valid Cloverelaf Data Types.
Thus, although I have not yet begun to construct the use of clock to replace the convert_date functionality, I suspect it will not be as ergonomic as convert_date without a lot more work.
convert_date was very useful when working with Cloverleaf provided data types and converting from one valid data type to another.
I did not get nor did I ask for any explanation as to why this command that has been around at least for 14 years has been deprecated.
I did, however, inquire if there were any other Cloverleaf provided Tcl commands that have been deprecated.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
Replies
-
-
I just received notification that this is being added as a bug.
We have also been advised to devleope a work around using the clock command until this is fixed (I am assuming at this point there will not be a correction in Cloverleaf(R) 5.6).
To those of you who are not sure or do not think you are using this command, if you are using the $HCIROOT/contrib/hl7_ack.tcl proc (or some derivative) you most likely have convert_date in play.
Also, the way convert_date is used in that proc assures the resulting date/time stamp (in Cloverleaf 5.6 at least) will not be correct as long as this bug exists.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
I have done some additinal research and it appears convert_date may not be broken.
Here is what I have concluded:
Now that the default is no precision for DATECOPYOPT, this affects the functioning of convert_date outside of the Xlate as well (tps procs for example).
Thus when we do:
convert_date ch “” ts 12
convert_date returns:
2010 <–this is the current year only, not what we expect.
However, if we do this:
convert_date -configure
and then:
convert_date ch “” ts 12
we get:
201001051125 <–This is the full date/time that we were seeking.
We can also do: convert_date -configure
-
ch “” ts 12.
If we do (with ADDPREC on) convert_date ch “” ts 19, we get:
20100105112800-0600 <–We are on Central time so the offset is correct.
So apparently the ADDPREC affects not only the inclusion of the precision for convert_date but also whether the current date and time are used to complete missing format elements.
So it appears one needs to make sure ADDPREC is set properly. Now the question is if this is set in a tps proc, does this now affect the default for any Xlates in that site or is the ADDPREC setting only effective for the interpreter in which it is executed (maybe only for the actual proc in which it is issued)?
I have presented my findings to support.
I will rpost here if and when I get answers to my above questions.
I apologize if my previous post caused any anxiety for anyone.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
