2

I have changed my user Time Zone to "Pacific Daylight Time (America/Los_Angeles)". When i retrieve it through apex code(Timezone class) i'm getting result as "Pacific Standard Time (America/Los_Angeles)". Does there any work around to fix this? And does it effect Timing differences?

  • SFDC uses GMT for all datetimes saved in the database and then renders the time when displayed per the running user's timezone. Are you trying to replicate this behavior? – cropredy Apr 13 '16 at 1:39
  • @cropredy I think this is a different question, it sounds to me like Rv1 has changed the time zone settings for a user, but the system is showing that user as having a different timezone. In this type of situation, I imagine the system would only let users choose Pacific time and then automatically handle the switch to daylight savings time, but it would be interesting if users could explicitly choose Standard vs Daylight time for the Pacific region. – martin Apr 13 '16 at 2:05
4

Background

I set up a user with Timezone = (GMT-07:00) Pacific Daylight Time (America/Los_Angeles)

Using the methods of the TimeZone class, I confirm that

tz.getDisplayName() returns Pacific Standard Time and,

tz.toString() and tz.getId() returns America/Los_Angeles // the Java TimeZone class supported value

but, of course, the times shown in the debug log or in the standard UI are reflective of the running user's specified timezone --that is, on August 17, 2016, I ran the test when DST is in effect, and times on the UI matched my watch.

N.B. There is no Timezone method that returns the combined string Pacific Standard Time (America/Los_Angeles) (V37.0)

So, as far as the UI is concerned, no need to worry. Any date or datetime you retrieve via SOQL will be in UTC. These values are automatcially converted to the user's timezone if you use the standard UI or apex:inputField or apex:outputField VF components.

And, any user-entered date (datetime) is converted (if coming from the standard UI, Apex Date.today(), DateTime.now() or apex:inputField to UTC by the platform based on the running user's timezone and is DST-aware.

Now, you might also ask ...

Let's look at the available timezones (for US users so list isn't too long)

enter image description here

Some things to note:

  • There is no entry for Pacific Standard Time (something we would think of as GMT-08.00). Clearly, sysads don't set up users residing in the great state of California (say during a non-DST month) as Pitcairn Standard Time, no matter how much they might want to mutiny :-).
  • What we can infer from the list of timezones, is that the user/sysad should choose a DST-labeled timezone for the user (regardless of day-of-year) if the user resides in a location that honors DST. So, a user in the great state of New Jersey should be assigned Eastern Daylight Time (America/New_York), not Eastern Standard Time (America/Panama). Panama does not honor DST (close to equator - no reason to). This is confirmed by the User field documentation that states:

Users in Arizona should select the setting with “America/Phoenix,” and users in parts of Indiana that do not follow Daylight Savings Time should select the setting with “America/Indianapolis.”

  • Or, and here's the key, the value of the TimeZone class getId() method is used by Salesforce to adjust for DST as the calendar flips over day-by-day through our progression around the sun. America/Phoenix and America/Panama never adjust for DST but America/Los_Angeles does. Furthermore, the framework SFDC uses (based on Java I would suspect) is aware of the actual calendar datetime when DST goes on and off - and there is a separate calendar for each of the possible values of getId()
  • The display name in the User setup doesn't agree with the value returned by tz.getDisplayName() but what matters is the ID.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.