We are trying to change the date format to display “MM-DD-YYYY” . But By default all the date pickers and date format displayed as “YYYY-MM-DD” in the openemr.
As per our initial understanding, we can not store the date with different formats in database.(as default date format in MySQL is YYYY-MM-DD )
So what ever format we going to use,everything should convert and store in the database as “yyyy-mm-dd” . And retrieving and displaying from the database also needs the conversion process. (Correct me if i am wrong here).
Is any other way handled in openemr to change the data format ?
I believe still this project is on-going .Is anyone started the data format conversion in the openEMR code-base?
Yes. Its available and its working good in displaying the data formats as a string(12-03-2012).
But in “Date Picker and it’s text boxes” still older format (2012-12-03) only displaying in all the places.
For this Date format changes in all the date pickers, here our approach.
OpenEMR already has a function called DateToYYYYMMDD() to convert any date format into format that is suitable for DB storage . We have used this function to transform the date format before insert query executes and have used the oeFormatShortDate() function for displaying the date in desired format.
We have also written a functionality such that whenever the date format is changed in the Admin->Globals->Locale the date format in the library files of “Date Picker” are replaced by the chosen format such that the format of Date Picker is visible in throughout the instance.
By this method we have to use the DateToYYYYMMDD() function before all the queries in OpenEMR and oeFormatShortDate() function in all the respective text box of the picker to displaying desired date.
Is this method advisable?
Share your views here.
Thanks . We did some initial changes in the Library files and added one File (date_format.php) for “Change the data picker” formats depends on the Globals.
I placed some comments in the commit.
My primary criticism is that AJAX doesn’t seem appropriate for notifying the javascript what date formatting string to use. It doesn’t change frequently, so making it poll across the network every time is a poor design choice.
As per the suggestions we have modified the dynarch_calendar_en.inc.php file to get the format from the globals and use DateFormatRead() function which is a default OpenEMR function present in the formatting.inc.php file.
We could also make the dynarch_calendar_setup.js to get the new_format values (without using AJAX) from the dynarch_calendar_en.inc.php file if the files are included in pages in the following sequence:
1. dynarch_calendar.js - The Calendar object is created here
2. dynarch_calendar_en.inc.php - the value for new_format is obtained from DateFormatRead() function
3. dynarch_calendar_setup.js - uses new_format value from dynarch_calendar_en.inc.php
In this case, we need to include all these files in all the required files.so that we don’t need to use any extra methods to change the formats.
Here our commit for the data format change and its implemented in “encounters” for testing purpose.
we can change the desired date format in global settings.
Looked at code an tested it. I think you’re on the right track. However noted the following issues:
1. Why the / getting replaced with a - after entering in a date on the new encounter form.
2. This breaks all the date inputting in other places (for example, if set in globals to m/d/y and then go to demographics dob and enter something it goes to year 2185.
Thanks for Testing the same.
For Point 1,
We retained the separator “-” which is used at most of the instances of date picker. We can also use the “/” as the separator for some data formats in the Test box. so only we used. If it’s Not need, we can avoid that “/” separator.
For Point 2,
The date picker uses the value of the textbox to bring about the current date.
Since it is not in the format that is required, the picker receives wrong values thereby showing the wrong date.
This can be solved by using the oeFormatShortDate() function in the textbox.
For point 1, will it be much more difficult to uses slashes rather than - when applicable?
For point 2, how feasible will it be for you to change the entire codebase to support this. Additionally, guessing bad things may happen to custom forms/code etc. Can you think of a way to support both new and legacy behavior(then wouldn’t require a complete code refactor also)?
Hi Brady,
For the issues noted in the early commit,
1. Why the / getting replaced with a - after entering in a date on the new encounter form.
2. This breaks all the date inputting in other places (for example, if set in globals to m/d/y and then go to demographics dob and enter something it goes to year 2185…
We are done the changes to over come the issue. For that, In the date picker, if the “ifFormat” (which is used to specify the date format) is given a value “useGlobals”, it display the date based on the format specified in Globals.
In this case only date pickers that use “useGlobals” will get affected and not the others.
For the fields that we specify “useGlobals”, the oeFormatShortDate() should be used for display and DateToYYYYMMDD() for storing in DB as mentioned before.
So where ever the change need for the “Date change” we can use this functions. else we can leave the existing code base.
