27

How can I go about displaying a date that is formatted to a users locale, for example me and my Australian friends use the format dd/MM/yyyy, while the Americans amoung us use MM/dd/yyyy. I know I can format a date in visualforce like so

<apex:outputText value="{0,date,dd/MM/yyyy}">
    <apex:param value="{!myDateValue}" /> 
</apex:outputText>

but how can I use the salesforce locale, There is a complete list but how can I use these on my page?

I have found a very comprehensive solution here, but I was hoping someone new of an inbuilt, or more elegant way.

Daniel Blackhall
  • 7,882
  • 10
  • 50
  • 68
  • 1
    Have you tried just using {0,date,short} or {0,date,long}? – Matt Lacey Aug 16 '12 at 01:39
  • I have not, I was not aware that was possible. This works perfectly, Thanks Matt! btw you should have posted this as an answer – Daniel Blackhall Aug 16 '12 at 06:36
  • Fyi, this doesn't work for me. Regardless of the user's locale the short, medium, and long date formats are always in US format. – Ralph Callaway Jan 10 '13 at 02:34
  • @DanielBlackhall any chance you tested this out before closing my question as duplicate? The {0, date, short} does NOT respect locale with me. If it's not working for you would you mind voting to reopen my other question and save me the trouble of asking it again? – Ralph Callaway Jan 26 '13 at 00:45
  • 1
    @Ralph I don't know what reopening your question is going to do, It is obviously a Salesforce bug. Good work getting it to tier 3. It's strange because it used to work, so it may take less than 2-4 years to fix (revert whatever change was made internally). – Daniel Blackhall Jan 26 '13 at 04:06
  • @DanielBlackhall you're right, realizing editing this question made more since anyway, thanks for responding. – Ralph Callaway Jan 28 '13 at 15:04
  • @DanielBlackhall unfortunately this may be coming true. I just got informed from R&D that apex:outputtext "has always been un-respectful of user locale." and that while fixing it makes sense they'd rather not since "the rest of our customers are using it the way it has been from the beginning" and changing it would negatively affect them :( – Ralph Callaway Feb 27 '13 at 00:42
  • 1
    @Ralph I finally got around to testing this again, and you're right it's not respecting the locale. It's also preposterous, how would displaying the correct date for the locale negatively affect customers! – Daniel Blackhall Feb 27 '13 at 01:53

2 Answers2

23

The easiest way to do this might be to utilise the 'named' date formats that are available, for example, short and long:

<apex:outputText value="{0,date,short}">
    <apex:param value="{!Opportunity.CloseDate}" /> 
</apex:outputText>

<apex:outputText value="{0,date,long}">
    <apex:param value="{!Opportunity.CloseDate}" /> 
</apex:outputText>

BUG ALERT

While official documentation hints that message formats respect locale, currently the named messages formats (short, medium, and long) always output in US date format (month then day) or possibly the locale of your instance. A support request was logged and R&D replies that this won't work and will never work

This is "working as designed." OutputText has always been un-respectful of user locale. For user locale specific data you need to use OutputField. While addressing this may fix the issue for you the rest of our customers have been using it this way from the begin. While MessageFormat.java does talking about using locale, it uses the locale of the localhost only, not the running users.

Ralph Callaway
  • 24,529
  • 17
  • 112
  • 190
Matt Lacey
  • 25,618
  • 7
  • 66
  • 149
  • 2
    there is also a medium (dd MMM, yyyy), which ended up being perfect for my purposes – Daniel Blackhall Aug 16 '12 at 06:39
  • Fyi, this doesn't work for me. Regardless of what locale is specified for the user the date format is always a US date format. – Ralph Callaway Jan 10 '13 at 02:33
  • @Ralph Did you double check that your locale is not US? Should be no reason for it not to work... – Matt Lacey Jan 10 '13 at 02:37
  • @LaceySnr for sure, I've got a test page with outputfield and outputtext. When I change my locale to 'English (United Kingdom)' the outputfield displays the date in dd/MM/yy, but the outputtext (using the {0, date, short}) displays MM/dd/yy, are you not experiencing the same thing? – Ralph Callaway Jan 10 '13 at 02:46
  • Going to have to do some tests now ;) – Matt Lacey Jan 10 '13 at 03:12
  • 5
    @LaceySnr fyi, logged a bug for this which is with Tier 3, so they should have a fix in 2-4 years – Ralph Callaway Jan 26 '13 at 00:41
  • This still shocks me that a bug is "working as designed" if something has always had a bug. The idea that fixing the issues will affect existing customers is a non-argument for a platform that has api versions and consistently changes behavior after a specific api version. – Ralph Callaway Apr 22 '20 at 16:59
16

If you can use the Salesforce outputField component instead of outputText, it will automatically adjust to the locale of the context user.

If you have a custom controller or extension on your page, the instance method format() on the Date primitive will return the date as a string formatted in the user's locale.

Opportunity.CloseDate.format()
Brane
  • 1,012
  • 11
  • 12
Rob Scott
  • 769
  • 1
  • 4
  • 12
  • Good answer, I only used the close date as an example for my snippet (which I have edited for clarity) – Daniel Blackhall Aug 16 '12 at 06:37
  • You can still use format() in Apex if 'myDateValue' is of type Date - myDateValue.format(). – Rob Scott Aug 20 '12 at 21:13
  • 1
    To make outputField valuable in a wider range of scenarios, you could create a "Types" sObject, which would (among other things) have a Date field. In your controller you would use an instance of this sObject rather than a simple Apex Date value, and bind your outputField to this sObject field. You could wrap it all up in a custom component whose controller has an instance of your Types sObject; you would pass in the date value to the component with an assignTo your types sObject field, and use an outputField to render the value. – Stephen Willcock Jan 28 '13 at 11:05