Well, it was rather a low priority task (due to its possible difficulty), but it has been advancing so well in just two days that I think I can already make a little preview on this...
First of all, I'd like to officially welcome Guillaume Viguier-Just, who joined forces with us just yesterday. Guillaume has a considerable PHP development experience, so it's been pretty easy for me to give him a few basic tasks in Chamilo and it's apparently been pretty easy for him to honor them. I'm looking forward to all the good things he will be able to give the Open Source community in the next few months of his collaboration with us. No need to explain Mercurial, PHP, timezones, Ubuntu or coding conventions: he's been getting to work straight on. Great time savings!
Then let's explain the timezones problem...
We had a problem in Chamilo, that all instances of Chamilo portals installed on the same server have to share the same timezone (namely because there was no timezone management in Chamilo or its ancestors). This effectively meant that we, as hosting providers, had to have 1 server for each timezone available in the world if we wanted to have customers all over the world, which would have meant much more expenses and hosting prices shooting up.
So I decided to go ahead and create requirement #599
, which is in fact a group of 3 tasks:
- identify and analyse what the current time management process generates (in terms of times recorded on the system) and consequently all timestamp fields were converted to datetime (to have a unique time base all over Chamilo)
- implement a portal-based timezone feature (allowing various portals on the same server to serve distinct timezones)
- implement a user-based timezone feature (allowing users from the same portal but living in areas with distinct timezones to see all hour-based time references in their own time-base)
My estimation was that it would be a "20 points" task in our own SCRUM-based estimation, and it seems I've been right (it will take a few days to implement).
We discovered that the MySQL TIMESTAMP field type is UTC-based
(Universal Time), while DATETIME
is not. DATETIME is based on a parameter of MySQL, called time_zone, which holds the difference between the local time and UTC. Taking into account the fact that TIMESTAMP also has a logical limit at 2038-01-19 (which is already giving us problems in Chamilo) while DATETIME has a limit at 9999-12-31, we decided to switch everything to DATETIME in the Chamilo database. Of course, this is all taken care of by the migration scripts, and we checked that the difference between UTC and local time was not lost.
With this basis analysis and type changes, Guillaume was ready to implement a global function (api_get_local_time()), which will be used from now on to display time in the timezone set inside the portal configuration, and later to display it in the user's own timezone. So finally, we will have timezones management (at the same time as UTF-8 management) in Chamilo. A great leap forward for the software and our community. I will discuss the move to UTF-8 later on, on this blog.
This means that, starting next week, we will update our development portal (still to be moved to another URL) and you will be able to try out the timezone feature for yourself through your user profile! Stay tuned for an update to this post...
Let me mention that we wouldn't be able to do all this without the financial investments of our customers and community members who help us making Chamilo a far better software than its ancestor, the "D" project, used to be.