620346 - DateTime::new does not pass the 'an integer which is a possible valid day of month' callback if PostgreSQL server has datestyle parameter not set to "iso, dmy"

Status: NEW

(Bugzilla :: Database, defect)

Description

[Stefan Oberwahrenbrock]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: version 3.6.3

Displaying bugs created after some specific date or creating new bugs users get thow following error message (partly "censored" with "xxx"):

The 'day' parameter ("2010") to DateTime::new did not pass the 'an integer which is a possible valid day of month' callback
at lib/x86_64-linux-gnu-thread-multi/DateTime.pm line 199
DateTime::new(undef, 'HASH(0x3dfc3c8)') called at Bugzilla/Util.pm line 460
Bugzilla::Util::datetime_from('15.12.2010 09:30:51') called at Bugzilla/Bug.pm line 2764
Bugzilla::Bug::comments('Bugzilla::Bug=HASH(0x3e02a20)', 'HASH(0x3e02a50)') called at Bugzilla/BugMail.pm line 360
Bugzilla::BugMail::Send(30, 'HASH(0x3e01c88)') called at /var/www/xxx/bugzilla/post_bug.cgi line 255
For help, please send mail to the webmaster (xxx), giving this error message and the time and date of the error.




Reproducible: Sometimes

Steps to Reproduce:
Setup Bugzilla 3.6.3, with PostgreSQL database backend, PostgreSQL server has "datestyle = 'german' globally configured in "postgresql.conf"

Actual Results:  
The configuration was setup round about at the end of November 2010 and worked for about 2 weeks without problems. The the above mentioned error occured on creating new bugs and on displaying already created bugs, that were created after a specifc date (~10th of December, don't know exactly any more). I do not know, why this configuratin first worked and then suddenly stopped working. Sounds weird, but that was the behaviour I observed :-/


The problem can be solved with the following modification to the bugzilla database in case, changing the global server configuration is not an option:

ALTER DATABASE bugzilla SET datestyle = 'iso, dmy';

Maybe this could/should be done by the installation script to circumvent the problem. I initially reported that phenomenon on the mainling list (http://groups.google.com/group/mozilla.support.bugzilla/browse_thread/thread/677291c2b2427ca3#). I set severity for this problem to "Critical" because after the problem came up, our Bugzilla installation was not useable any more. But I also think, most PostgreSQL servers are set to 'iso, dmy' as default - thus serverity is probably only critical for some (rare?) installations.

Comment 1

[Max Kanat-Alexander]

The only reason that this isn't critical is that it affects very few installations.

But yeah, we should do that ALTER DATABASE when we create the database.