I was having some problems with DateTimes on FME Cloud (East Coast cluster) and managed to come up with a solution, but decided to do some reading and checking. I can confirm that my instance is set to Central time, as is my admin account.
For some reason, DateTimeNow() returns time in UTC with no offset shown. So my main question: is this by design? It's not the same behavior as in FME Server, so I have to make specific adjustments to workspaces - bummer. I did a quick search and came across a very good and detailed article about the subject by @mark2atsafe . Towards the bottom, it states:
- Timezones and FME Server: I’ve always had problems with timestamps when I’m in one timezone (Central -6:00) but FME is running on a cloud-based server in a another timezone (say Pacific -8:00). Now I don’t have to worry. The DateTimeNow() function lets me specify standard UTC time, so it doesn’t matter where my server is based. I can also ask for local time both with or without timezone.
Well, it seems the function just returns UTC, regardless of whether you leave the default () or add "local" (DateTimeFormat was applied to the result):
To address this, you have to either do a timezone adjustment by first adding a timezone to the UTC time with a zero offset, and then adding the actual timezone (-5 hours to display the actual time at the data center), or just doing a DateTimeAdd directly. Here are the formulas I used:
- Timezone adjustment A: @DateTimeFormat(@int(@TimeZoneRemove(@TimeZoneSet(@TimeZoneSet(@DateTimeNow(), -00:00), -05:00))),%I:%M:%S %p (%A - %d %b %Y))<br>
- Timezone adjustment B: @DateTimeFormat(@int(@DateTimeAdd(@DateTimeNow(),-PT5H)),%I:%M:%S %p (%A - %d %b %Y))
And the results:
The @int function was used to remove the fractional seconds, which were not important for my use case. Both methods yield the same results, with the B formula being slightly shorter and easier to decipher. So, is it by design that FME Cloud is always returning UTC and is the above always required? Thanks!
