Recently I had implemented changes at a customer which required the use of the Job Queue to run a process at 6AM every day & generate sales data.
As this is not an unusual request, I created the relevant report to run & generate the data, set up the job queue, added a new server instance for the NAS, tested the setup was working and informed the customer all was well and that the data would be generated each morning.
The first day, the data was generated at 6AM. Subsequent days saw the NAS job run at 7AM. Greatly puzzled by this I checked the Job Queue setup, the logs & the Job Queue codeunits to see if a reason for the change of time could be found. Unable to find a cause, I decided the change must have been human intervention, re-set for 6AM and left it to run again.
The next day, the job queue was set back to 7AM. Still unable to fathom why this may be I discussed the issue with my most esteemed colleagues (mostly in order to ensure I was not going mad). During the discussion a colleague reminded me that the clock on the terminal server was always ahead, which caused the issue to click – the server is setup in French, as we were implementing for the UK arm of a French company. Realising that the change in time could only be due to the NAS running in UTC, setting the time to 0600, and the server itself then converting the time to CET and adding the extra hour on. I poked further into the language settings & discovered in the NAV server instance the ‘Default Service Time Zone’ setting:
With this set to “Server Time Zone”, and a quick restart of the service the NAS was soon back to running on time.
It’s worth noting that this can also be set to a specific time zone as well, if required.