[rt-users] TicketSQL Date parse weird..

[Stuart Browne]

> > <snip>
> >
> > 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.

Ruslan,

I’m using RT 3.8.8 at the moment.  did some tests this morning (before the 10-hour's from UTC) and all the times aligned.  With your patch, the worded time was off by TZ:

#
# BEFORE 10AM
#

#
# Before patch
#
[bekar at psg-apps tmp]$ ./test.pl
current time() output:          1339111474

fixed-date Time::ParseDate:     1339200000
tomorrow 10am Time::ParseDate:  1339200000

fixed-date RT::Date output:     1339200000
tomorrow 10am RT::Date output:  1339200000
timezone according to RT::Date: 36000
timezone according to RT::Date: 36000

#
# After patch
#
[bekar at psg-apps tmp]$ ./test.pl
current time() output:          1339111434

fixed-date Time::ParseDate:     1339200000
tomorrow 10am Time::ParseDate:  1339200000

fixed-date RT::Date output:     1339200000
tomorrow 10am RT::Date output:  1339236000
timezone according to RT::Date: 36000
timezone according to RT::Date: 36000

This was fine all the way until there was TZ seconds until the end of the day (after 14:00 for me).  Results from that period:

#
# After 14:00
#

#
# Before Patch
#
[bekar at psg-apps tmp]$ ./test.pl
current time() output:          1339128542

fixed-date Time::ParseDate:     1339200000
tomorrow 10am Time::ParseDate:  1339200000

fixed-date RT::Date output:     1339200000
tomorrow 10am RT::Date output:  1339286400
timezone according to RT::Date: 36000
timezone according to RT::Date: 36000

#
# After Patch
#
[bekar at psg-apps tmp]$ ./test.pl
current time() output:          1339128507

fixed-date Time::ParseDate:     1339200000
tomorrow 10am Time::ParseDate:  1339200000

fixed-date RT::Date output:     1339200000
tomorrow 10am RT::Date output:  1339236000
timezone according to RT::Date: 36000
timezone according to RT::Date: 36000

So the un-patched is definitely wrong.  The patched is more consistent but sadly still wrong.  Perhaps putting the removal of TZ back in to get the expected result more consistently:

#
# Additional line
#
[bekar at psg-apps tmp]$ ./test.pl
current time() output:          1339139429

fixed-date Time::ParseDate:     1339200000
tomorrow 10am Time::ParseDate:  1339200000

fixed-date RT::Date output:     1339200000
tomorrow 10am RT::Date output:  1339200000
timezone according to RT::Date: 36000
timezone according to RT::Date: 36000

Coming up to a public holiday here so I won't be in a position to do any testing until Tue/Wed next week.  I'll try it again before 10-am to see if I get a consistent result.

Stuart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alternate-date.patch
Type: application/octet-stream
Size: 1083 bytes
Desc: alternate-date.patch
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120608/94dd1013/attachment.obj>