[rt-users] TicketSQL Date parse weird..

[Ruslan Zakirov]

On Thu, Jun 7, 2012 at 11:51 AM, Stuart Browne
<stuart.browne at ausregistry.com.au> wrote:
>> -----Original Message-----
>> From: rt-users-bounces at lists.bestpractical.com [mailto:rt-users-
>> bounces at lists.bestpractical.com] On Behalf Of Kevin Falcone
>> Sent: Thursday, 7 June 2012 1:00 PM
>> To: rt-users at lists.bestpractical.com
>> Subject: Re: [rt-users] TicketSQL Date parse weird..
>>
>> On Tue, Jun 05, 2012 at 06:06:09PM +1000, Stuart Browne wrote:
>> > When doing a TicketSQL search similar to the following:
> <snip>
>>
>> RT actually passes a number of arguments to parsedate:
>>
>> grep can find where it's called (not in SQL.pm)
>>
>> $ grep -r Time::ParseDate::parsedate lib/
>> lib/RT/Articles.pm:        my $seconds = Time::ParseDate::parsedate(
>> $args{$date}, FUZZY => 1, PREFER_PAST => 1 );
>> lib/RT/Date.pm:        my $date = Time::ParseDate::parsedate(
>>
>> -kevin
>
> Ok, further test (see attached perl routine):
>
> [root at psg-apps tmp]# ./test.pl.txt
> current time() output:          1339054410
>
> fixed-date Time::ParseDate:     1339113600
> tomorrow 10am Time::ParseDate:  1339113600
>
> fixed-date RT::Date output:     1339149600
> tomorrow 10am RT::Date output:  1339200000
> timezone according to RT::Date: 36000
>
>
> Using either 'user' or 'server' as the timezone I get the same result but I'm probably missing something here for the fixed-date (I can accept that the date might be being modified elsewhere I'm yet to find), but the 'tomrorow 10am' shouldn't be a full day off.  So the adding of the timezone offset before Time::ParsEdate::parsedate then removing it again appears to be causing the issue here; pushing today past the end of the day boundary.
>

I can believe it's wrong. Time::ParseDate can do timezones, but
timezones support is very limited, so we do our timezones after
parsing in UTC. Understandably 'tomorrow 10am' in london while you're
somewhere else is completely different thing.

We do some compensation in NOW argument and in theory it should work.
Are you on the latest version of the module?

Never noticed before that ZONE argument can take whatever TZ
environment variable can take. May be attached patch will just work.
Have not tested it. Applies cleanly to 3.8 and 4.0.

> I'll try this routine tomorrow morning (before 10am) to see if it shows the right thing, then try to figure out a way to get it to return the same result for the two RT::Date outputs.
>
> Stuart



-- 
Best regards, Ruslan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RT-4.x-use-parsedate-timezones-support.patch
Type: application/octet-stream
Size: 1187 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120607/4fde2f4c/attachment.obj>