Failing unit test in test/general/Scheduler.cfc

hacking
1

When I run the unit tests I am getting this failure in test/general/Scheduler.cfc:

check next calculation for yearly
Expected [{ts ‘2021-11-01 02:01:01’}] but received [{ts ‘2021-11-01 01:01:01’}]

I am able to fix it by changing this line:

var next=ScheduledTaskThread.calculateNextExecutionNotEvery(DateTimeUtil.getInstance(), now, true, TimeZone.getDefault(), start, ScheduleTaskImpl.INTERVAL_YEAR);

To this:

var next=ScheduledTaskThread.calculateNextExecutionNotEvery(DateTimeUtil.getInstance(), now, true, TimeZone.getTimeZone('CET'), start, ScheduleTaskImpl.INTERVAL_YEAR);

I changed the call to calculateNextExecutionNotEvery to pass in the same timezone as the createDateTime calls are using. Has anyone else seen this issue? Does this seem like a reasonable fix?

2

Actually this fix doesn’t seem to work for some other timezones other than CET. I’m doing some more testing to see if I can figure out why.

3

It looks like I was wrong again. This fix does work for all timezones except for EST and MST. I don’t think those matter. You aren’t really supposed to use the short abreviated timezones anymore anyway.

4

Here is an example that tests them all TryCF.com

5

ah good catch, out of interest, what timezone are you in? @micstriit and I are both in CET (sigh aka works for us)

as the scheduler runs in the configured timezone for the web context, I think we should just be defaulting to the web context timezone?

the most reliable way to get that is using the following function, as while all the tests are meant to cleanup after themselves, it is possible that a different timezone was set

6

I’m in US/Mountain time. I can try to fix this issue sometime soon. I didn’t get much time to look at this stuff today. I will probably have a pull request in for the lsweek unit test in a day or two. Then I have one more failing unit test that I’ll post about. Then they will all be passing for me.

7

Excellent, are U running locally on Mac Windows or Linux?

8

I’m running the tests locally on a Mac.

9

I finally had time to look at this. I understand what you are saying now about using the getRegional action to get the timezone. This won’t work in a unit test will it, since it requires the admin password.

For the unit test do you think the fix I have would work, or should it be done some other way?

10

the tests run with a configured admin passwords, see here?