This change prevents from registering and/or saving the profile of a
user with the whitespace instead of the required name.
Additionally, there is accessibility improvement for better error labels
in case of missing values (copied over from signup_form).
This patch replaces all homegrown timezone
stuff with standard PHP date/time code.
The main change is the introduction of core_date
class that returns normalised user and server
timezones. From now on nobody should be using
$CFG->timezone or $user->timezone directly!
Other new features and fixes:
* admins are prompted for timezone during install
* editing of other users is finally fixed
* timezones are displayed in user profile
* new $this->setTimezone() in phpunit
* time locale is now automatically reset in phpunit
* timezone is now automatically reset in phpunit
* phpunit has Australia/Perth as default timezone
When an additional name field is not enabled in the admin settings the
text box should still be available to fill out in a section further down
the page (Additional names).
If the language string is missing firstname or lastname, then when displaying the
user edit form it defaults to 'firstname lastname'
Previous logic has been moved out to new functions with unit tests.
1) Moved the calendar types location to a sub-folder in the calendar directory.
2) Removed/moved language strings.
3) Removed calendar types that should be downloaded as plugins.
4) Removed a Non-English language pack for the Gregorian calendar type that
should be downloaded separately.
5) Removed custom files responsible for checking for updates and uninstalling
calendar types, which should be done by core.
6) Removed JS from the calendar_month block as there is no non-JS alternative
provided and the JS written does not make use of the YUI library to ensure
multiple browser support.
7) Removed code from the base class responsible for creating timestamps that
are saved in the DB.
8) Added PHPDocs.
Note: In the original patch we are editing core functions responsible for saving
time in the database in the calendar base class. This is very dangerous, we do
not want to touch these functions as it could cause a complete fubar of the
database. There are places we are forcing the use of the gregorian calendar as
we are passing dates generated by the PHP date function, where as sometimes
we pass dates from usergetdate (which was being overwritten to return the
date specific to the calendar). We can not expect third party modules to
change the calendar type depending on the format they pass to these functions.
GD PHP extension is now required. Add-ons need to remove $CFG->gdversion tests. The worst case regression is that add-on will think GD is not available.
