digdag schedules output timezones confusing about digdag HOT 5 CLOSED

Why is that confusing? What do you think better?
"session_time" has concept of years, days, hours, etc. as numbers. They're important because workflow often uses timestamp formatted in text. Therefore digdag CLI shouldn't convert it to local time.
Next run time is different. Formatting means nothing for machines. It's OK to use local time for humans.

from digdag.

Maybe it's just that I'm confused about session vs run time.

from digdag.

Are there any docs/material where I can read up on the significance of session vs run time?

from digdag.

That is extremely very important concept but no documents!!

Well, for example, you have a workflow that runs every day. It puts results to a table on TD with date's suffix like result_20160412. You'll use create_table: [result_${last_session_date_compact}] option with td> operator.
Query will be like this:

select count(*) from data
where TD_TIME_RANGE(time, '2016-04-12 00:00:00 -0700', '2016-04-13 00:00:00 -0700')

which will be written in workflow definition as following:

select count(*) from data
where TD_TIME_RANGE(time, '${last_session_time}', '${session_time}')

But you noticed that you can't run the workflow at 00:00:00 because data is not ready at 00:00:00. You need to delay the start time for 3 hours. In this case, session_time should be 2016-04-13 00:00:00 -0700, but run time should be 2016-04-13 03:00:00 -0700.

This also happens when you retry the workflow. If you retry it 1 week later, run time is 1 week later but session_time should be consistently 2016-04-13 00:00:00 -0700.

from digdag.

Ok, that makes sense, thanks for explaining! =)

from digdag.