I have a need to express dates in UTC time. I'm currently using the string:

{DATEFORMAT(yyyy-MM-ddTHH:mm:ss.fffZ)}

which spits out the date in compliance with the ISO 8601  standard. (Meaning that the Z should indicate UTC time.) However, it does no conversion, so it's really just spitting out the current system time.

Of course, I could do a MATH operation to add/subtract, but this will be deployed across multiple timezones, and would become incorrect when Daylight Savings goes into effect.

Windows is aware of its UTC offset, so accessing this should be fairly straightforward, but I have no idea how difficult it would be to implement in VisualCron. Still, I think it should be a pretty useful feature for anyone deploying across time zones.

Thank you in advance!

The more I work with them, the more I see that the different date functions are not agreeing with one another. As an example, if you evaluate the expression:

{DATEADD(Seconds|{DATEFORMAT(yyyy-MM-ddTHH:mm:ss.fffZ)}|yyyy-MM-ddTHH:mm:ss.fffZ|1|yyyy-MM-ddTHH:mm:ss.fffZ)}

It should return the current date/time plus one second. However, for me (at UTC -04) it is returning a time 4 hours in the past.

The inner expression {DATEFORMAT(yyyy-MM-ddTHH:mm:ss.fffZ)} will return my local time, but with a Z at the end. (Which incorrectly indicates that it is UTC time.)
The outer expression {DATEADD(Seconds|...|yyyy-MM-ddTHH:mm:ss.fffZ|1|yyyy-MM-ddTHH:mm:ss.fffZ)} correctly interprets the Z as UTC, then converts it back to my local time by subtracting 4 hours.

In order for this to work, I need to have some way to return the current date/time in UTC, or to convert any date to UTC. I can't simply add 4 hours, because that value is not a constant. (Changes with Daylight Savings) Additionally, this will be deployed on machines across different timezones.

I was looking for something else and came across this post.
This might be more precision than you need, and isn't exactly what you asked about, but it might get you closer.
There is an undocumented format option:

{DATEFORMAT(o)}

It returns a proper datetime with zone designator; with that, you should be able to get the UTC.

As a test, I tried adding one second like you did and got incorrect results:

{DATEADD(Seconds|{DATEFORMAT(o)}|o|1|o)}

This one returns correctly.

{DATEADD(Seconds|{DATEFORMAT(o)}|o|1|yyyy-MM-ddTHH:mm:ss.fffZ)}

This one incorrectly returns local time with a Z appended to the end.

So there definitely seems to be something odd about this behavior.

Here is the format guide: https://docs.microsoft.c...-and-time-format-strings 

Maybe you wanted to have zz in the end instead.

---

Resurrecting this old thread because I figured out a way. I wanted to take the last execution time of a job, convert it to UTC, and format it in a way that's compatible with my SQL database.



{JOB(bd76db8f-eff2-4314-b6ae-356824fc537a|LastRun|zz)} gives us the timezone offset from the last time the job was run. We then invert it by subtracting it from 0. That allows us to add that number of hours to the date and get the UTC timestamp.

When Daylight Savings occurs, {JOB(bd76db8f-eff2-4314-b6ae-356824fc537a|LastRun|zz)} will update with the new offset the next time the job runs. This ensures you're always adding/subtracting the correct number of hours to get the UTC timestamp.

For your purposes, all you'll need to do is change {JOB(bd76db8f-eff2-4314-b6ae-356824fc537a|LastRun to whichever variable you need.