Batch children details condition compare date to start time

[Dan Power]

I have one job in a batch that they don't want to run until after a certain date. I thought the condition field could work for that. However, I am getting all or nothing depending on my comparison sign. For example, say the start time is today (20260121).

These all allow the job to run. But logically they should all fail.

int("20260120000000") >= int($starttime)

20260120000000 >= $starttime

"20260120000000" >= "$starttime"

These all fail when I am expecting them to succeed.
int("20260122000000") <= int($starttime)

20260122000000 <= $starttime

"20260122000000" <= "$starttime"

I used the run command to check the value of $starttime and see it in YYYMMDD.... format but I read one post that said dates could be in epoch depending on where they are used. All I was to do is suppress one job in the batch until after a certain date. I know I can do it with an interval, but creating one time use interval just sounds like a bad idea. Hence why I was looking at the condition. But I don't see where I can see the value that is used by the condition for $starttime. Just what I can get from job run. Maybe I am not looking in the right place on how the condition was evaluated to get to the results like I can see for the run command on the job details. As such, I suspect I am not comparing what I think I am comparing.

[Ronald Jeninga]

Hi Dan,

good to hear from you!

Even if it is a little late: Happy New Year! :-)

Now to your issue.

The $*time parameters are in epoch if evaluated in a trigger context (originally) and in expressions (those were added later).

This allows halfway easy date arithmetic (e.g. if the job didn't finish 2 hours after start, trigger some notifier) but is cumbersome in your case because you'll have to find that magic number first.

The utility "date" is your friend, like in

$ date '+%s' -d '2026-01-26 00:00:00'
1769382000

And the condition

1769382000 < int($starttime)

or so, should evaluate to true from January 26th on.

Note that the job will be submitted nevertheless, but it will be disabled, which means that it'll not be executed and will terminate with the final exit state with lowest preference (usually SUCCESS).

Hope that helps, but if it doesn't work as expected, please tell me.

Best regards,

Ronald

[Dan Power]

Haha, you remember me? It has been a long while. I had a good new years, yes.

1769068800 = today at midnight
1769155200 = tomorrow at midnight curtesy of timestamp-converter . com

Here is what happened today at around 2pm

int(1769068800) <= int($starttime) runs disabled

1769068800 <= int($starttime) runs disabled

1769068800 >= int($starttime) runs enabled

1769155200 >= int($starttime) runs enabled

1769155200 <= int($starttime) runs disabled

int(1769155200) <= int($starttime) runs disabled

What I am expecting is something that will do both
today@midnight <= int($starttime) runs enabled

tomorrow@midnight <= int($starttime) runs disabled.

But I am just not getting that result. I really wish there was a way I can inspect $starttime as it is being used for the condition so I am not working blind. Then I can figure out what I am doing wrong. But this is like black box testing.

[Ronald Jeninga]

Hi Dan,

I'm not 100% sure if I understand what you'd like to achieve, but I just created a test job and specified the following condition

1769122800 <= int($submittime) and (1769122800 + 86400) > int($submittime)

where 1769122800 is January 23rd, 2026 at 00:00:00, as is shown using date:

$ date '+%s' -d '2026-01-23 00:00:00'
1769122800

Now date is aware of my time zone (MET, GMT+1) and your results can differ.

Also note that 86400 is the number of seconds in a day (most of the time; some days are shorter, some are longer, both factual and felt like).

Anyway, the system acted as expected and enabled the child job.

Changing the condition (e.g. with tomorrow's epoch time) made the system disabling it, again as expected.

Furthermore it is crucial to test a timestamp that has been set.

$starttime is set as soon as the job is fetched by a job server and has been started.

This means that it is at best zero before that happens.

Also the condition is evaluated at submit time which is earlier than the time that your job reaches the RUNNABLE state (and can be fetched by a job server).

Hence the only timestamp you have is the $submittime

If your job is part of some long running batch and its possible start is likely to be hours or even days after submit, the condition isn't the correct method.

In such a case you'd need something like a test job that tests the actual time and if the test is successful, the intended job can be triggered. 

You can inspect $starttime in several ways.

The, I find, best method is to issue a "show job 12345;" in the GUI shell and find the start time.

Another option is to display the starttime on the monitoring page.

Or you look at the timestamps and statistics tab.

In all cases the start time is shown in a readable format and you can ask date to convert that to epoch, if you need that.

Sorry I didn't think about the $starttime parameter in my previous answer.

I concentrated too much on the time format used in expressions, not on the queried parameter.

Best regards,

Ronald