When the app starts does it read any sort of configuration file which might contain a timezone or time offset? i.e something like a config.fpw file which gets read by the scheduled version, but not in your testing?

Can you post the code which is giving incorrect results?

>Hi
>
>I am the one who set up the scheduled task via RDC. I am in the same time zone as the server.
>
>Simon
>
>>Is it possible that the person who set up the scheduled task is in a different time zone from the server? If they're getting a server-local session via RDC or similar that shouldn't matter, but if they're connecting say via VPN and using some sort of remote session (i.e local to them), it might.
>>
>>Speaking of VPN, if something like that is in use, is it possible the VPN appliance's time zone is incorrect? Alternately, could it be a site-to-site VPN with the endpoints in different time zones?
>>
>>Finally, thinking way outside the box, is it possible the app being scheduled to run was built in a different time zone and then transferred/installed XCOPY-style rather than with a Windows installer? I'm not sure how this would cause what you're seeing, though - just throwing the thought out there.
>>
>>>Hi
>>>
>>>I signed into the server using the same credentials as the service and the time was correct but the service is still out by 3 hours.
>>>
>>>Simon
>>>
>>>>Funny you should mention that because I was just thinking the same thing. So the answer is no but I will check it now.
>>>>
>>>>Thanks,
>>>>Simon
>>>>
>>>>>>Hi
>>>>>>
>>>>>>I have VFP processes that run on Windows Servers and notice that if I run the process from the VFP command window the result from the DateTime() function matches the local time. However if I then run the same code as a Scheduled Task in Windows then the result from the DateTime() function is out 3 hours. So if the local time is 5:30am then the DateTime() reports 2:30a. This only happens when run from ShellExecute() as a compiled executable or in the Task Scheduler. Upon further investigation I discovered that the WinAPI GetLocalTime() does exactly the same thing.
>>>>>>
>>>>>>This is happening on all my Windows Servers (2012, 2016 and 2019). However, they all have the correct time zone setting and the clocks all display the correct local time (EDT). So I had to created my own functions that retrieve the server's UTC time and convert it to local time which works just fine. However, I wondered if others have seen this type of behavior.
>>>>>
>>>>>Have you checked the regional settings for the account under which you're running the scheduled tasks?