> > <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@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@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@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@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@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
alternate-date.patch
Description: alternate-date.patch
