Analytics temporal functions may treat timezones differently than query service

For temporal functions that accept a timezone and an output format (e.g. MILLIS_TO_TZ), the results of certain formats may differ from the query service:

millis_to_tz(1467356400000, "EST", "TZN")

The given millisecond time represents 2016 July 1, which would mean Eastern Time would be in Daylight Savings, meaning the query service will actually convert from EST to EDT for its result. In the analytics server, the literal timezone EST will be used and a conversion to EDT will not be done. 

In some cases (such as this example), a "larger" timezone such as EST5EDT which represents Eastern Time more holistically will allow both services to make the conversion.
 

millis_to_tz(1467356400000, "Europe/Istanbul", "TZN")

With this on the query service, the result would be EEST, while on the analytics service, it will be TRT. In terms of offset, these timezones are equivalent, but they have different names.
 

millis_to_tz(1467356400000, "EDT", "TZN")

Certain timezones like EDT or PDT will work as input for the tz parameter in the query service, but not the analytics service (where this will return null). Java does not recognize EDT, PDT, and others as timezones.

now_local("TZF")

Using the formats such as this or "TZF" with a function that uses the local timezone on the query service will return "Local", while on analytics, it will return the timezone (such as "America/Los_Angeles")