Every 2E model has functions that are no longer required, yet they persist and continually get reused. A good example of this common issue is the continued usage of legacy date conversion routines that exist in most 2E data models.
How many of you have the following functions (or very similar) in your model?
The reason why is quite simple!
They were probably written long before 2E supported the date fields indicated. After all, the DT8 (Date 8) and DT# (Date ISO) were added relatively late in the tools evolution.
I recall working at a company in London (pre 2000), who had solved the Y2K problem by transitioning their date fields from DTE to an user defined field type CDT (Century Date), this was basically a DT8 i.e. YYYYMMDD but implemented way before 2E had supported it. I believe 2E were quite late to the party and implemented DT8 support around 1999. Synon Inc started supporting the DT8 field specifically for people transitioning their models from DTE to DT8 and to help overcome any potential Y2K date rollover issues within their code. There was even a model analysis tool that helped people identify these issues.
The problem is..... Many sites had already solved their issues (as above), whilst others stuck with the DTE format and its limitations and perhaps only targeted certain field like DOB. I reckon there are dozens of sites around the world that continue to define dates as DTE out of habit! I would be guilty of doing so for sure.
Anyhow, for those that have moved on and are defining DT8 or DT# or TS# (ISO Timestamp), I still believe that many programmers will be using the self coded legacy functions to perform date conversion. I know I have too been guilty of this crime from time to time in the heat of coding.
The thinking goes something like this?
- Navigate to your system functions or date functions (scoping file DFN).
- Filter on Date or Convert (cnv) and pick the function that suites your needs.
- Test function and everything works fine.
- Great, Job done!
However, there is one small flaw with this. You didn't need to use the legacy date conversion functions anymore. Remember, these were likely written before 2E supported the source or target date format or have been written more recently by a developer who didn't realise that 2E already handles automatic date conversion between its (shipped) data types.
As long as you are moving data from a field type that is supported and that it has 'date like' data in it, 2E will automatically handle the conversion
for you.
The table below (directly from the 2E online documentation) helps showcase all the automatic conversions that are handled by 2E and below that a table highlighting the limitations or rules.
* Conversions for the shipped D8# and the user-defined DT8 (8-digit internal representation) data types are identical.
What does this look like in the code? Well let's take a look at some generated code to find out.
The following 'mock up' function is trying to covert the DTE (*JOB DATE) to a DT# (ISO) and DT8 format.
The ISO conversion is a little more complicated and is also generated into a subroutine so that it can be called for any date conversions from DTE to DT#. The DTE to DT8 conversion is something I am sure you have done many times in code using the *ADD etc these are generated inline and not passed to a subroutine due to the small number of lines of code.
The subroutine code for ISO is below.
A final point to note is that if you have a number field of 7.0 length masquerading as a date, you can move it into a date field DTE date. Same with 8.0 to DT8, which will be more common if interfacing to data derived from more modern databases that never had a history of supporting dates like DTE or Julian.
You can then apply 2E date functions as usual.
Finally, we are not limited to dates, times and their myriad of formats are also interchangeable.
Thanks for reading.
Lee.
