Indeed it does fix it, dates display perfectly, apparently in my localtime too.
I have noticed some peculiarities when setting the dates though.
I’m not nesseccarily complaining, I just got enthusiastic testing it.
First off, the results gives the time in GMT, not localtime.
All the following are attempts at setting a date to 30th July 2001
My local time is GMT+1, my PGDATESTYLE is postgres, European
In summary, the following formats are okay:
Jul 30 2001
Jul 30 2001
30 Jul 2001
2002 - Will set to today’s date in the year 2002
Also, you can set the time with hh:mm or hh:mm:ss either before or after any of the above. Using just the time will set it to that time today.
Here’s everything I tested. If somebody is bored, and want’s to check if on their install, especially mysql and oracle, I’m sure it’d be of use to Jesse.
30/Jul/2001 - Correct
30/07/2001 - Date gets set to epoch - Doesn’t recognize that I’m european
Jul/30/2001 - Date set to epoch - Funny that it gets this one wrong
07/30/2001 - Correct - American format.
Seems like if you specify the month number, it assumes american formatting,
if you specify the month name, it assumes european formattinh
Using “-” instead of “/” has the same effects
Once you drop the / or - things get weirder.
Jul 30 2001 - Correct
07 30 2001 - Date set to 26th July 2007 03:59:00 GMT
30 Jul 2001 - Correct
30 07 2001 - Date set to 26th July 2007 03:59:00 GMT
So it gets it right either way, when using the month name with no delimiters
2001 Jul 30 - Date set to epoch
2001 07 30 - Date set to 25th Jul 2001 18:00:00 GMT
So never put the year first.
20010730 - Date set to epoch
Mon/mon/monday/Monday - Jul 26 2001 23:00:00 GMT
Specifying the day only sets it to today.
jul/Jul/July - epoch
30 jul - correct
30 07 - Jul 26 2030 17:00:00 GMT
jul 30 - correct
07 30 - Jul 25 2007 18:00:00 GMT
Again, it get’s it right when using the month name
2002 - Jul 26 2002 23:00:00 GMT
30 - Jul 26 2030 23:00:00 GMT
07 - Jul 26 2007 23:00:00 GMT
So specifying just the year works, if you use two or four digits.
Use one digit though, and you end up having that number of hours subtracted from the start of today:
1 2001-07-26 23:00:00 GMT
2 2001-07-26 23:00:00 GMT
3 2001-07-26 23:00:00 GMT
Using three digits, and a similar thing happens, with the last two digits being subtracted as minuts:
001 2001-07-26 23:59:00 GMT
110 2001-07-26 22:50:00 GMT
190 2001-07-26 21:30:00 GMT
So Julian dates are out.
0 just sets it to the epoch though, as 0000.
70-99 are assumed to be 19xx and 01-37 are taken to be 20xx
00 is set to the epoch though, not 2000
Anyway… back to real work
-Feargal.On Fri, 27 Jul 2001 01:28:10 -0400 Jesse email@example.com wrote:
DBIx-SearchBuilder 0.41, which fixes this issue, has just entered CPAN.
I’d love to know that this fixes things
On Fri, Jul 27, 2001 at 12:17:49AM +0100, Feargal Reilly wrote:
This is casued because your postgres has a PGDATESTYLE other than ISO.
DBIx-SearchBuilder doesn’t allow for this at present.
To fix it,
Make the following change to /DBIx/SearchBuilder/Handle/Pg.pm
After line 26, where it reads:
$self->SimpleQuery(“SET TIME ZONE ‘GMT’”);
$self->SimpleQuery(“SET DATESTYLE TO ‘ISO’”);
This will ensure that RT connections are handed the correct datestyle,
and all your other databases will be unaffected.
Don’t forget to stop and restart your mod_perl apache.
On Thu, 26 Jul 2001 18:43:24 +0200 Sebek Pavel Pavel.Sebek@i.cz wrote:
Hi there. I recently installed 2.0.4 and upon playing, I see "Not set"
everywhere a time and date should be. Everything else seems to work…
Mandrake 7.2 x86
Apache-1.3.14 with mod_perl
testdeps passes without a problem
Can anybody help me please
Rt-devel mailing list
jesse reed vincent – firstname.lastname@example.org – email@example.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90
There are no supercomputer applications that are solvable that cannot be solved
in finite time using a fucking TRS-80 with approprite disk/tape drives. Zero.