Ticket created from CLI script with wrong Due date; timezone issue?

I have the following code being run by a cron job to create a ticket every
Tuesday at 11am (Australia/Melbourne) with a due date of Wednesday at 11am
(also Australia/Melbourne, so 24 hours later):

use RT ();
use RT::Date ();
use RT::Interface::CLI ();
use RT::Ticket ();

RT::Interface::CLI::CleanEnv;
RT::LoadConfig;
RT::Init;

my $due_date = RT::Date->new($RT::SystemUser);
$due_date->Set(
Value => ‘11am Wednesday’,
Format => ‘unknown’,
);
my $ticket = RT::Ticket->new($RT::SystemUser);
$ticket->Create(
Queue => ‘’,
Subject => ‘’,
Due => $due_date,
);

The ticket is created at 11am Tuesday (as expected), with a Due time of
11am Tuesday (not expected–should be 11am Wednesday). What am I doing
wrong?

It looks like something could be wrong in the way RT::Date calls
Time::ParseDate:

$ grep ‘11am Wednesday’ rt-debug.log
… [debug]: RT::Date used Time::ParseDate to make '11am Wednesday’
1402362000 (…/RT/Date.pm:240)

$ TZ=Australia/Melbourne perl -e 'warn scalar localtime(1402362000)'
Tue Jun 10 11:00:00 2014 at -e line 1.

I’m running RT v4.2.3 at the moment with the latest version of
Time::ParseDate at this time (v2013.1113). RT configuration variable
$Timezone is set to ‘Australia/Melbourne’.

For what it’s worth, the server running the cron job has its timezone set
to ‘America/Los_Angeles’, but as the cron job fires at the correct time, I
don’t think this contributes to the problem.

There’s an error in the code I posted earlier. I’m actually creating the
ticket like this:

$ticket->Create(
Queue => ‘’,
Subject => ‘’,
Due => $due_date->ISO( Timezone => ‘UTC’ ),
);

my $due_date = RT::Date->new($RT::SystemUser);
$due_date->Set(
Value => ‘11am Wednesday’,
Format => ‘unknown’,
);
my $ticket = RT::Ticket->new($RT::SystemUser);
$ticket->Create(
Queue => ‘’,
Subject => ‘’,
Due => $due_date,
);

Ticket->Create doesn’t consume an RT::Date object, it expects ISO in
the user’s timezone. Running your code as provided, I get no Due
Date and
[63270] [Tue Jun 17 19:26:57 2014] [warning]: Couldn’t parse date
’RT::Date=HASH(0x7fbd94003618)’ as a ISO format (lib/RT/Date.pm:209)

I’m guessing something else is setting your Due date.

-kevin

That was just a transcribing error on my part. I call a method on the
RT::Date object to get the date out in the expected format; a later message
in this thread shows the corrected code.

At any rate, the debug output is indicating a problem even before that
point.On 18/06/2014 5:28 am, “Kevin Falcone” falcone@bestpractical.com wrote:

On Tue, Jun 10, 2014 at 12:21:35PM +1000, Alex Peters wrote:

my $due_date = RT::Date->new($RT::SystemUser);
$due_date->Set(
Value => ‘11am Wednesday’,
Format => ‘unknown’,
);
my $ticket = RT::Ticket->new($RT::SystemUser);
$ticket->Create(
Queue => ‘’,
Subject => ‘’,
Due => $due_date,
);

Ticket->Create doesn’t consume an RT::Date object, it expects ISO in
the user’s timezone. Running your code as provided, I get no Due
Date and
[63270] [Tue Jun 17 19:26:57 2014] [warning]: Couldn’t parse date
‘RT::Date=HASH(0x7fbd94003618)’ as a ISO format (lib/RT/Date.pm:209)

I’m guessing something else is setting your Due date.

-kevin


RT Training - Boston, September 9-10
Training — Best Practical Solutions

That was just a transcribing error on my part. I call a method on the RT::Date
object to get the date out in the expected format; a later message in this
thread shows the corrected code.

At any rate, the debug output is indicating a problem even before that point.

If you have a reduced sample that doesn’t require Ticket->Create to
expose, show that, probably with some debugging output so it can be
run locally. Additionally, you may want to look into the config,
there are relevant parsing options around ‘Wednesday’.
http://bestpractical.com/docs/rt/latest/RT_Config.html#Date-and-time-handling

In addition, keep in mind the timezone of the user used to create the
date object and how that plays into this.

And remember, RT in no way requires you to use an RT::Date to
calculate Wednesday at 11am. This is perl, there are about 50 ways to
do it.

-kevin

The code posted in my original message, minus the $ticket->Create call,
generates debug output showing the problem independent of ticket creation.
In that message I’ve highlighted the discrepancies in that debug output in
red. Your comments on that specific output would be greatly appreciated.

I don’t believe that the date/time configuration options are relevant,
because I’m explicitly specifying “11am Wednesday” in an RT::Date->Set call
and getting an epoch for “11am Tuesday.” My timezone is not offset from
GMT by 24 hours.

I want to be able to enter freeform text and have it interpreted relative
to the RT-configured timezone, hence my use of RT::Date.On 19/06/2014 5:38 am, “Kevin Falcone” falcone@bestpractical.com wrote:

On Wed, Jun 18, 2014 at 10:53:11AM +1000, Alex Peters wrote:

That was just a transcribing error on my part. I call a method on the
RT::Date
object to get the date out in the expected format; a later message in
this
thread shows the corrected code.

At any rate, the debug output is indicating a problem even before that
point.

If you have a reduced sample that doesn’t require Ticket->Create to
expose, show that, probably with some debugging output so it can be
run locally. Additionally, you may want to look into the config,
there are relevant parsing options around ‘Wednesday’.

RT Config - RT 5.0.3 Documentation - Best Practical

In addition, keep in mind the timezone of the user used to create the
date object and how that plays into this.

And remember, RT in no way requires you to use an RT::Date to
calculate Wednesday at 11am. This is perl, there are about 50 ways to
do it.

-kevin


RT Training - Boston, September 9-10
Training — Best Practical Solutions

The code posted in my original message, minus the $ticket->Create call,
generates debug output showing the problem independent of ticket creation. In
that message I’ve highlighted the discrepancies in that debug output in red.
Your comments on that specific output would be greatly appreciated.

I don’t believe that the date/time configuration options are relevant, because
I’m explicitly specifying “11am Wednesday” in an RT::Date->Set call and getting
an epoch for “11am Tuesday.” My timezone is not offset from GMT by 24 hours.

Since RT::Date uses Time::ParseDate, I’m not sure that your syntax is
valid.

Time::ParseDate is going to default to shenanigans when you feed it
bad data.

I’m not yet convinced of an actual RT::Date bug here, just bad input
to ParseDate and timezone confusion (remember whose timezone is
applied when you create an RT::Date with the System User).

use lib ‘./lib’;
use RT -init;

my $due_date = RT::Date->new($RT::SystemUser);
$due_date->Set(
Value => ‘11am tomorrow’,
Format => ‘unknown’,
Timezone => ‘America/New_York’,
);
print $due_date->ISO;

works fine for me, using days in the parser does not, but that does not
surprise me, Time::ParseDate is fragile, although doesn’t try to use the
Julian calendar as often as other parsing modules.

Have you considered

-kevin

RT::Extension::RepeatTicket doesn’t suit my specific needs, so I’m
implementing a solution using scrips and templates.

I should have given more regard to your earlier remark about the time
parsing configuration options—after playing with Time::ParseDate
separately, I determined that PREFER_FUTURE needs to be set. Setting
$AmbiguousDayInFuture to 1 has fixed my problem.On 20 June 2014 02:31, Kevin Falcone falcone@bestpractical.com wrote:

On Thu, Jun 19, 2014 at 11:25:52AM +1000, Alex Peters wrote:

The code posted in my original message, minus the $ticket->Create call,
generates debug output showing the problem independent of ticket
creation. In
that message I’ve highlighted the discrepancies in that debug output in
red.
Your comments on that specific output would be greatly appreciated.

I don’t believe that the date/time configuration options are relevant,
because
I’m explicitly specifying “11am Wednesday” in an RT::Date->Set call and
getting
an epoch for “11am Tuesday.” My timezone is not offset from GMT by 24
hours.

Since RT::Date uses Time::ParseDate, I’m not sure that your syntax is
valid.

Time::ParseDate - date parsing both relative and absolute - metacpan.org

Time::ParseDate is going to default to shenanigans when you feed it
bad data.

I’m not yet convinced of an actual RT::Date bug here, just bad input
to ParseDate and timezone confusion (remember whose timezone is
applied when you create an RT::Date with the System User).

use lib ‘./lib’;
use RT -init;

my $due_date = RT::Date->new($RT::SystemUser);
$due_date->Set(
Value => ‘11am tomorrow’,
Format => ‘unknown’,
Timezone => ‘America/New_York’,
);
print $due_date->ISO;

works fine for me, using days in the parser does not, but that does not
surprise me, Time::ParseDate is fragile, although doesn’t try to use the
Julian calendar as often as other parsing modules.

Have you considered
RT::Extension::RepeatTicket - Repeat tickets based on schedule - metacpan.org

-kevin


RT Training - Boston, September 9-10
Training — Best Practical Solutions