nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

WFtask SetTimeout and GMT?

Adam Stoller

Environment[indent]TS 7.3.1 on W2K8[/indent]
Issue[indent]In an external task script - if I take a TeamSite::WFtask object (the task was defined with a timeout of

"+002400"

) and try to change the timeout to an absolute value - like

"052120120945"

(Mon May 21 09:45:00 2012), the result appears to be set to the GMT value (represented as seconds since epoch)

"1337593500"

(Mon May 21 04:45:00 2012) - but is activated within the context of the server's actual timezone (which in this case is ET).

...
my $timeout1 = "052120120945";
$task->SetTimeout($timeout1);
$task->Refresh;
my $timeout2 = $task->GetTimeout();
$log->debug("$timeout1 <=> $timeout2 (" . localtime($timeout2) . ")");

Has anyone else encountered this issue? (and if so - found a "reasonable" way to fix it?)

I'm also curious if anyone else can reproduce this issue, and with what versions of TS on what OS (and in what timezone).

I currently only have access to the one environment[/indent]

Find more posts tagged with

Comments

Adam Stoller

Doh! I thought about this as I was driving back to the hotel from the office - and I believe the behavior is as-expected as opposed to as-I-thought-it-was-doing.

GetTimeout() of a task with a timeout specified as an absolute time shows the value as seconds-since-epoch in GMT - which, while confusing, is not necessarily wrong (it would be nicer if it maintained the format it was given)

GetTimeout() of a task with a timeout specified as a relative time shows the value as "+SSSSSS" (again, it would be nicer if it maintained the "+HHHHMM" format).

The server is, I believe in ET.
The client (both in terms of being my customer, and the desktop machine ;-) is in CT.

I.e.: At 09:30 CT / 10:30 ET - I specified the timeout as "052120120945" (09:45) thinking that I was doing so in CT; however it was evaluated against the server's timezone and thus it was really entered as 09:45 ET / 08:45 CT - thus instead of giving myself a 15-minute lag time (as I was trying to do) I was actually setting the timeout 45-minutes in the past.

The fact that the timeout is shown as seconds-from-epoch-in-GMT just confused the issue to the point where I thought I was dealing with a 5-hour discrepancy instead of just a 1-hour discrepancy, and thus I overlooked what should have been [more] obvious.

At least this is my current theory, which I'll probably verify tomorrow (although I already threw together the code to do the relative timeout conversion ;-)

Adam Stoller

Sigh - Wrong on my revised hypothesis.

The server is actually in CT - so the time I'm specifying and the server's time are within the same time zone.

The fact that I'm getting the timeout back from the workflow as seconds-since-epoch GMT might actually be a bug in TeamSite.

I'm doing one more test right now:

Rick Poulin

[QUOTE=ghoti]

I have seen this before.. I believe we were running TS6.7 on Win2k3. That said, I suspect that this difference in the API is a PERL-specific thing with TeamSite::WFtask and they'll probably have to live with it lest an upgrade throw workflows everywhere out of whack. I haven't seen this same problem with CSTask.getTimeout() and CSTask.setTimeout() in Java, which handle timezone information much better.

Adam Stoller

I have seen this before.. I believe we were running TS6.7 on Win2k3. That said, I suspect that this difference in the API is a PERL-specific thing with TeamSite::WFtask and they'll probably have to live with it lest an upgrade throw workflows everywhere out of whack. I haven't seen this same problem with CSTask.getTimeout() and CSTask.setTimeout() in Java, which handle timezone information much better.

FYI - the delay worked exactly as expected (using the 5-hour adjustment)

Also, I realized afterwards that it's not GMT - it's 1 hour off of GMT (GMT would be -6 hours not -5) so it looks like it might be a combination of GMT and not handling DST correctly.

I decided to throw together a script to test things out using a static task (one that has a timeout value but which is not currently active) - and now I'm more confused than ever because the results appear to be correct.

Somehow, somewhere, in my original code I must be doing something very strange.... this is looking more like "user-error" hmm ...

Sean_Hanck

Interestingly enough, an old post of yours 5 or 6 years back help me resolve this issue back then. If I can remember properly, I just plain gave up on trying to set the time out to a specific time and created a util method that figured out the time difference between my timeout in date() format and now and translated that into seconds. With that info I always set my timeout with the since epoch and not with a date, when using perl.

Does that make sense? Timeouts always give me a headache.

Adam Stoller

User error - of a sort.

My actual code was using Date::Manip - and from experiences long ago, where I ran into issues because Windows did not set a timezone environment, I had explicitly added:

...
BEGIN {
    $ENV{TZ} = '-0600';
};
use Date::Manip;
...

It turns out that I do not need to explicitly set the TZ environment variable - at least not on [this] W2K8 64-bit server. Date::Manip appears to be happy without it - and more-to-the-point the results of setting the timeout on the task are happy as well.
From my test program:

C:\>h:\settimeout.ipl
======================================================================
$ENV{TZ} = ''
======================================================================
Using CLT directly - set timeout on task for 1 hour
FROM CLT: '+3600'
FROM OBJ: '+3600'
Using CLT directly - set timeout on task for 2012-05-23 02:39 (052320120239)
FROM CLT: '1337758740'
FROM OBJ: '1337758740'
LOCALTIME: Wed May 23 02:39:00 2012
Using CLT directly - set timeout on task for 1 hour
FROM CLT: '+3600'
FROM OBJ: '+3600'
Using WFTask object - set timeout on task for 2012-05-23 02:39 (052320120239)
FROM CLT: '1337758740'
FROM OBJ: '1337758740'
LOCALTIME: Wed May 23 02:39:00 2012
C:\>h:\settimeout.ipl
======================================================================
$ENV{TZ} = '-0600'
======================================================================
Using CLT directly - set timeout on task for 1 hour
FROM CLT: '+3600'
FROM OBJ: '+3600'
Using CLT directly - set timeout on task for 2012-05-23 02:39 (052320120239)
FROM CLT: '1337740740'
FROM OBJ: '1337740740'
LOCALTIME: Tue May 22 21:39:00 2012
Using CLT directly - set timeout on task for 1 hour
FROM CLT: '+3600'
FROM OBJ: '+3600'
Using WFTask object - set timeout on task for 2012-05-23 02:39 (052320120239)
FROM CLT: '1337740740'
FROM OBJ: '1337740740'
LOCALTIME: Tue May 22 21:39:00 2012

In the immortal words of Homer J. Simpson - Doh! :-)

Adam Stoller

Sigh - the saga continues ... briefly

My tests yesterday with / without setting $ENV{TZ} worked because I wasn't actually making use of the Date::Manip routines in my test code.

As soon as I try to do something like:

my $now = ParseDate("now");

the script will fail because it cannot figure out the timezone information (which is what I had recalled from the past as being a Windows issue)
[indent]Side note: It doesn't matter if I use "-0600", "CDT", or "CST" - all three result in the same return value from things like

ParseDate("now"); ParseDate("today at 22:00");

etc.[/indent]

I believe I figured out how to fix this though - again using my test code (which now includes date parsing routines).

...
BEGIN {
    $ENV{TZ} = "CST";
};
use Date::Manip;
...
my $time = ParseDate("today at 22:00");
my $timeout = UnixDate($time, "%m%d%Y%H%M");
$ENV{TZ} = undef;
$task->SetTimeout($timeout);
...

This appears to work.

Closing thread again...