Set Calendar time zone

[apooravc]

This PR adds a global calendar_timezone which the user could use to select his/her time zone for Calendar date/time functions. date_default_timezone_get (used as default time zone for Calendar) gets the value of date.timezone in php.ini file if it is valid/supported (valid time zones given here) otherwise defaults to UTC. The user selected time zone from Main globals or User specific globals (given more preference when different values) is set as date.timezone configuration option value using ini_set.

date function is used to fill entries in date & start_datetime columns in patient_tracker and patient_tracker_element tables respectively. @teryhill Yet to add other time zones (list here). Should I add all of which are given there? Or go for a particular set covering major regions in time zones?

[teryhill]

look at the demo files at full calendar. get-timezones.php, get-events.php and utils.php.

[aethelwulffe]

xlt table entry here is "Calcutta" I suppose, but I guess you would not need that if you live in the time zone! Were these values added for a particular reason? Is there a time-zone gui widget you can grab somewhere?

[apooravc]

These were sample values added just for testing code initially. Added all valid time zones in second commit.

[aethelwulffe]

I knew that! :)

[apooravc]

Used iteration through timezone_identifiers_list to create an option list of all valid time zones in the second commit. Also when time zone in php.ini is same as one of the time zones in option list, the Default option disappears, so used ! as an identifier for Default option in such case. Eg: UTC as php.ini value and UTC is also in timezone_identifiers_list; in this case, Default option won't be there in option list if ! is not concatenated also. @teryhill @aethelwulffe Please have a look.

[apooravc]

In the third commit:

1. Moved global check code from library/patient_tracker.inc.php to interface/globals.php to cover (set) time zone all over EHR and not just Calendar.

2. Added reference to globals.php from patient_tracker.inc.php file.

Note about ini_set function: "Sets the value of the given configuration option. The configuration option will keep this new value during the script's execution, and will be restored at the script's ending." Referring here to those scripts which will use date functions which depend on time zones. Needs to be tested wherever time is involved. @teryhill Please have a look.

[aethelwulffe]

Good idea. This stuff has been on todo lists for a while. One place for time stuff, and only one place.

[teryhill]

Testing it with the developer mode in the updater. works great.

[apooravc]

@teryhill Also, this PR was first intended to be used to set time zone for Calendar only but now it can be applied to whole of EHR. So, should I let global option for setting the time zone remain under Calendar sub-section or should I shift it to somewhere else (and if shifting, then where)?

[teryhill]

Move it to under the Systems tab

[teryhill]

Also look at moving your function from globals.inc.php to edit_globals.php.

[apooravc]

@teryhill The code creating $zone_opt_arr (line86-106) right? Is it causing errors?

[teryhill]

@apooravc it is not causing errors. It is just "Cleaner" to have it outside of globals.

[teryhill]

is this needed?

[apooravc]

Yes, the code in globals.php uses ini_set to set the user selected time zone in Globals as time zone for the script in which globals.php is included. So, wherever date/time functions, this should be included in script containing such functions.

[teryhill]

It is called in a program that includes this one.

[apooravc]

@teryhill You mean that globals.php is called in edit_globals? Yes, but edit_globals only lets a user save his/her global option which could be then accessed by $GLOBALS['calendar_timezone']. Suppose we're saving an appointment, then patient_tracker.inc.php is executed only and without including globals.php here, the time zone for date function inside manage_tracker_status would not be saved according to user saved option.

[teryhill]

The time zone information is in globals.php, correct. Globals php is a main program that is loaded with the main code . Look at main.php, it is loaded there, look at patient_tracker.php , it is loaded there. patient_tracker.inc is used by patient tracker. Globals is called by the "Top" programs.

[apooravc]

@teryhill I looked up main.php and also checked again by making appt. without including globals.php, works correctly.

[apooravc]

Changes done in last two commits:

1. Removed include globals.php from patient_tracker.inc.php as it is included in main.php itself.
2. Changed global name from calendar_timezone to ehr_timezone as it now covers time zone all over EHR.
3. Moved time zone option list from Calendar to System tab in Admin > Globals and also moved code from globals.inc.php to edit_globals.php.

@teryhill Please have a look.

[aethelwulffe]

I am thinking that this will work for whatever conditions are required. It currently works. The idea to default to php.ini settings would be informational, but very often may be incorrect for the user. The real issue is cross-timezone organizations.

[teryhill]

This option is a user specific item also @aethelwulffe so if the user is in another time zone they can set there system for the different zone. Needs to have the / put back in so the locations are easier to determine.

[apooravc]

@teryhill Added back / to options so that user may find it easier to navigate to a time zone.

One more thing I noticed is that after moving global from Calendar to System tab, the time zone option list now only appears in Admin > Globals (Edit Global Settings) > System and not also in User Preferences (Edit User Settings). Back then it used to do in User Preferences (Edit User Settings) > Calendar.

[teryhill]

You need to add the "Systems" tag to the users.

[apooravc]

@teryhill Thought so, on it.

[apooravc]

@teryhill Added System tab to Edit User Settings. Please have a look.

[aethelwulffe]

OK, please tell me that these changes are final, and we can merge this. :)

[apooravc]

@aethelwulffe These changes are final.