Kathmandu misspelt Katmandu in timezone dropdown list
Being in Nepal, I have noticed this for a while.
/usr/share/zoneinfo/zone.tab has a correct standard entry Asia/Kathmandu
But the dropdown list in the webGUI has Asia/Katmandu and this propagates into config.xml
I noticed an effect of this in /tmp/PHP_errors.log
[10-Mar-2012 10:00:02 UTC] PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Asia/Katmandu' for 'NPT/5.0/no DST' instead in /usr/local/www/pfblocker.php on line 26
I wonder what other time-related effects there might be for pfSense systems in Nepal?
It would be good to put the "h" back into "Kathmandu".
We use the official TZ database, not one of our own making… So if it's a problem, it's upstream.
Now I see the problem:
Lists the name as Asia/Katmandu
But the official TZ database from http://www.iana.org/time-zones lists the name as:
So the official TZ database (which is part of FreeBSD) has a different name to the PHP data.
In my opinion (and the vast majority!) the correct spelling is Kathmandu, so I'll pursue this with the PHP site and see what can be done to correct it. This must be a long-standing hassle for stuff in Nepal.
Apologies - http://www.php.net/manual/en/timezones.asia.php contains multiple names for some places, e.g. "Asia/Katmandu" and "Asia/Kathmandu, "Asia/Calcutta" and "Asia/Kolkata". In my examples, the first is an older name and the second is the newer spelling (which is in common use in the countries concerned). So a list based on PHP's builtin knowledge would contain both spellings.
Actually, /usr/local/www/system.php uses the content of /usr/share/zoneinfo.tgz to generate the dropdown list of valid timezone names.
But in the pfSense distribution:
/usr/share/zoneinfo/zone.tab contains the newer spellings "Asia/Kathmandu" and "Asia/Kolkata".
/usr/share/zoneinfo.tgz has the older spellings "Asia/Katmandu" and "Asia/Calcutta".
At the moment, I am trying to see if these files have been provided inconsistently by FreeBSD.
zone.tab is a regular file provided in tzdata2012b.tar.gz which can be got from http://www.iana.org/time-zones - so I guess that it comes directly into FreeBSD from that source.
But zoneinfo.tgz is generated by some code somewhere - is it done in the FreeBSD distribution? or is it done by something that builds the pfSense images?
/usr/share/zoneinfo.tgz seems to be in pfSense Redmine as a real file, last updated in 2008 by revision http://redmine.pfsense.org/projects/pfsense/repository/revisions/f459ca1587f713c6b5af56235f112f9290ac6b25 so that means that it is not being rebuilt automatically from the zoneinfo data in each current FreeBSD release (i.e. from /usr/share/zoneinfo dir).
m0n0wall seems to have a Makefile that does this, but the stuff I could find on m0n0wall seemed to be really old. Comments in m0n0wall also indicate that they make zoneinfo.tgz themselves - see at the end of http://doc.m0n0.ch/dev/image-guide-rootfs.html - and thus the use of this file has been inherited into pfSense and FreeNAS.
FreeNAS has a recent Makefile at http://freenas.svn.sourceforge.net/viewvc/freenas/legacy/build/ports/zoneinfo/Makefile so the zoneinfo.tgz produced by a recent build of FreeNAS might be a good match for the /usr/share/zoneinfo/… data that comes with FreeBSD 8.3 It doesn't seem easy to find the individual build output binary files from these sort of builds. To get zoneinfo.tgz seems to require downloading the whole ISO image and then opening it up and finding/extracting the wanted file, which I haven't done yet.
Generating zoneinfo.tgz could be done as part of the automated build procedures to generate a pfSense-tailored FreeBSD - it would use the FreeBSD supplied zoneinfo folder and make a zoneinfo.tgz - that would ensure that the 2 data sources are always in synch. Or it could be made when pfSense boots, if the file does not exist (normally just on the 1st boot!), and remade as part of upgrade scripts.
How to proceed with this?
a) Just get a later zoneinfo.tgz from m0n0wall or FreeNAS and configure it (will need to be done again for each future release); or
b) Put a Makefile somewhere in the pfSense build process to generate zoneinfo.tgz as part of the build; or
c) Make it at boot time if it doesn't exist, and remake it during an upgrade; or
d) Don't use zoneinfo.tgz - modify any code that uses it to look in /usr/share/zoneinfo folders and extract the data from there at run-time (would slow down run-time loading of pages like the Time Zone Settings, the drop-down list would be generated on-the-fly from a more complicated set of input data)
Also to be considered, if zoneinfo.tgz is updated and has newer spellings for some old names, then there will be existing config.xml files that have out-of-date timezone names in them. That shouldn't be any worse an issue than it is now (with the names in the 2 places being out-of-synch and with new versions of FreeBSD that change the timezone names anyway), but there probably should be something to flag to the admin that the time zone selection is not valid. That might already be in error-handling code anyway.
Yeah I see it's in the repo, not sure what the best way forward is there. Open a ticket at redmine.pfsense.org and add the info you found. If nothing else we can generate a new copy and check it in.
There have recently been some copyright concerns with the TZ database, not sure where that stands now, but relying on remote copies probably isn't a good idea until all that blows over.
The lawsuit was resolved in Feb 2012 - see http://en.wikipedia.org/wiki/Tz_database#2011_lawsuit - so at least that is not an issue. The TZ database is now managed by IANA, so it has a well-defined public life! The Wiki page has the link to "Official IANA sources" at http://www.iana.org/time-zones but for pfSense we will normally just want to use whatever version is distributed with FreeBSD from time-to-time, so these official pages are an interesting reference, but there is usually no need to actually get the source data from there.
I will open a ticket today.