nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Problem with retrieving date info in current locale format

vladislavlysov

Hello!
I have a problem with retrieving date in user locale format. I have next webscript in alfresco:

(function () {
  var currentLocale = Packages.org.springframework.extensions.surf.util.I18NUtil.contentLocale,
        dateFormat = java.text.DateFormat.getDateTimeInstance(java.text.DateFormat.LONG, java.text.DateFormat.FULL, currentLocale);
  model.lastConnected = new Date().getTime();
  model.lastConnectedTime = dateFormat.format(obj.lastConnected);
… some code…
‍‍‍‍‍‍‍‍

And in Share i retrive this information with Yahoo UI and put them to DataSource. When i change my locale in browser and do GET reqest from browser to the Alfresco webscript, i get right info in Germany locale. But when i retrieve this info from Share(from YUI script), i have info in "en" locale. I don't understand, why?
Thank you.

Find more posts tagged with

Comments

mitpatoliya

If your date format is fix in which you always wanted to see your date
then you can use DateFormatter.
If you want that it should be user based then you need to extract the locale of the current user first.
Then set that locale as current language and then you should be able to see it in users native format.

davidcognite

Hello,

The best way to handle dates in webscripts is to return a consistent format from the server side webscripts (we use ISO8601) and then parse them on the client and format using the date-format.* formatting strings from common.properties. We've done it this way to avoid problems when the server is in one timezone/locale and the client is in another.

If you follow this method too, you should find that you don't run into any locale issues. The theory is that because the ISO8601 dates include timezone offset information when they get parsed and formatted client side the user's timezone offset as well as the locale specific formatting (from the i18n bundles) is taken into account by the browser.

HTH,
David.