Our business primarily operates in the UK and parts of our application validate based on dates and times. Our tests have recently started failing on TestCloud but they pass when running with Katalon Studio.
I believe I’ve now tracked this down to TestCloud operating from somewhere in America. This presents a several hour time difference that means the in browser validation does not perform as expected. We commonly run our tests early in the morning to minimise operational disruption.
As an example, if we run tests at 4am GMT through TestCloud then we will see failures in our date tests as in American time we are still in the previous day.
Ideally we want out TestCloud instance to be running on GMT time. Is there a way to set this up?
PS: I know that I can resolve this by running on an evening instead but given our TestCloud instance has changed location (the tests that are failing now used to pass in TestCloud before) I’d be concerned about this happening again.
I do not know TestCloud at all, therefore I ask you:
Is it possble for you to change the Time Zone setting in TestCloud?
In which geometrical region the server instance is located — it should not matter. You just need TestCloud to accept your preference in which Time Zone the software should work. Is TestCloud designed to accept your Time Zone preference?
If not, it’s a shame. It could be a good enough reason to stop using TestCloud. I would never recommend it to the people in Japan.
Other software projects let customers to change the prefered Time Zone. For example, Jenkins does as follows
That is for the server, so it will only work if the jobs are running on the master.
The same principle apply for TestCloud.
@scott.reid are you running your tests on TestCloud agents or you are using your local agents?
If second, you shoud check with the team administering those machines.
If first, that is a silly mistake from Katalon side.
Any sane server setup shoud use UTC, using localized timezone causes serious hadeache, particularily with logs.
The conversion to the user current time zone should be done by the web app based on the user workstation settings.
To check this, asuming you are running the jobs on a linux machine, you can check it by running the timedatectl command in a job and check the output.
For a windows agent, I have no idea how this can be checked.
We are currently running TestCloud via TestOps and there is no explicit option to set TimeZone when selecting a TestCloud environment. The only options available are OS, Browser and Browser Version.
Using TestCloud there is no direct access to the VM it is running from so I can’t configure that way. It may be possible to use project settings or browser arguments to set a timezone but I am yet to find a solution using this method.
Windows or Linux?
Altough my question is pure theorethical.
I have no idea what TestCloud use under the hood to spin up on-demand agents.
I am just guessing are AWS vm’s since this seems to be the preffered Cloud service used by Katalon to run various services (which is not a bad thing)
So I am just speculating.
From my experience with AWS, spinning up a Linux vm have, by default, set the timezone to UTC, e.g from a certain host I recently spin-up:
Local time: Thu 2023-03-16 14:03:12 UTC
Universal time: Thu 2023-03-16 14:03:12 UTC
RTC time: Thu 2023-03-16 14:03:12
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Anyway, I never used Windows instances so … I have no idea how that works in this case.
Could be that, with such type, the timezone depends on the AWS region the instance is running.
I repeat … I have no idea how TestCloud actually works.
Therefore pinging @vu.tran
Who can bring more light into this from Katalon side?
After further work I am now seeing tests passing with the following adjustments:
A test listener adjusts the time at the beginning of each test. This was also tested (and failed) with GMT and BST but Europe/London removed the failures. I’m assuming this matches the environment I am testing against:
The tests are now passing as expected when running through TestOps / TestCloud. I am hoping that is due to these changes but it could be that there have been other changes to TestCloud in the meantime.