You don't specify whether these machines are part of an Active Directory domain or not. I'll assume that they are not.
You don't specify what version of Windows you're running. The pre-Vista and post-Vista cataclysm is huge. It's practically an entirely different operating system. You can't just say "Windows" since Windows has changed a lot in its 20+ year history. I'll assume something Vista or above.
In the example you gave above, you are trying to run a program as Administrator, and to do that, you must supply the password for Administrator. There is not a direct equivalent of sudo in Windows. There does not exist a good way to embed Administrator credentials in the script or obfuscate them in some way that does not dangerously risk exposing the password to the standard user.
Anyway, you don't give permissions or access rights to programs. You give permissions to users, who execute programs. These programs execute in the security context of that user. The programs inherit their security privileges from the user who executed them.
You would use either Group Policy or Local Computer Policy (secpol.msc) to delegate this right to a user. Any user (or group of users) you like.
The technical name of the privilege is the
SeSystemtimePrivilege user right.
But wait there's more! Changing the system time is a privileged operation, and a user can cause a lot of havoc with the ability to change the system time, either maliciously or accidentally. Therefore, I do not think at this time you'll be able to change the system time as a standard user.
NTRights.exe -u JoeBlow +r SeSystemtimePrivilege from the 2003 Resource Kit basically does the same thing as adding the user to the "Change the system time" list in secpol.msc, and you'll still get the
A required privilege is not held by the client error. Even if you disable UAC, you still get the error. Keep in mind that the security token of a user is only calculated once at logon, so if you make changes that user's security token, they need to log off and back on again for the changes to take effect. But it doesn't matter - still it will not allow you to change the system time without elevating.
At this point, I would consider doing something like writing a Windows service or a scheduled task that ran as Local System that a standard user could interact with in some way that would manipulate the system time. It's pretty apparent that Windows didn't want standard user's screwing around with the system time.