Questions & Answers

[tlegat]

Hi there,

can somebody please explain to me why #global.node.page.getCreatedDate().format("yyyy-MM-dd") returns 2017-04-21 in the English language channel and 2560-04-21 in the Thai language channel? (We ignore the fact that getCreatedDate is not documented - it's a date.)

I found out that this refers to ThaiBuddhistDate (Java Platform SE 8 ) / ThaiBuddhistChronology (Java Platform SE 8 ) .

What actually triggers this behavior? I didn't supply a locale and our FS server contains lots of projects with varying languages.

Is there a "hidden" connection between the language definition in the server manager and the default behavior of format (eventually SimpleDateFormat (Java Platform SE 7 ) )

Using these dates for third services this returns "interesting" results.

[pavone · Accepted solution]

Hello,

I have not worked on this special part of FirstSpirit, but to me, it sounds like the desired behaviour.

In the ServerManager you set the ISO language and country codes for ervery FirstSpirit language. And if you format a date in the Thai language channel, to me it sounds sensible, that FirstSpirit (if no other Locale is provided) uses the ISO information for that particular language from the ServerManager to do this.

Or am I missing something here? Probably you have a use case, where this behaviour does not make sense?

Best regards,

Tim

[jstreit]

Hi!

The behaviour is quite what we expected. But not what we want here.

If you use this term:

$CMS_VALUE(#global.now.format("yyyy/MM/dd hh:mm"))$

You will get of course this:

Thai: 2561/11/13 05:52  (Thai solar calendar - The Suriyakati calendar (Thai: ปฏิทิน สุริยคติ ไทย, also: Thai solar calendar) is the currently used in Thailand calendar system. It is based on the world's most widely used Gregorian calendar, but uses the Buddhist era (BE) to count the years. Thus, the years are 543 larger than in the Christian era. 2017 → 2560.

German:  2018/11/13 05:30 

To get an overview of what is possible, you can also just try this here

    <h1>all  Zimezones</h1> 

    $CMS_VALUE(#global.now.timeZone.availableIDs.sort.toString("<br>"))$ 

    <h1>Print  timezones</h1> 

    $CMS_VALUE(#global.now.format("dd.MM.yyyy hh:mm:ss z"))$<br> 

    <br><br><br> 

    $CMS_VALUE(#global.now.timeZone)$<br> 

    $CMS_VALUE(#global.now.timeZone("America/Los_Angeles").format("dd.MMMM.yyyy hh:mm:ss Z","EN"))$<br> 

    $CMS_VALUE(#global.now.timeZone("Europe/Berlin").format("dd.MM.yyyy hh:mm:ss z"))$<br>

hope this helped you out ...

Greetings

Joachim Streit

[tlegat]

Hi pavone​,

if you had a purely Thai website you'd surely expect it to work that way, but would you when you have a corporate website that is deployed to many countries worldwide? Would you expect your analytics account to merge data which diverges by 543 years?

I understand if you say that we have to take care as developers but having a master project with centralized templates being rolled out into all those countries, I think that enhancing all concerned outputs of date with the locale argument simply bloats the code - as I require it only for one country (in this case).

Is there an option to set the date formatting for a certain language or a certain case? It would be lovely if I could define it for example once in the project settings output channel.

Joachim, thanks for the demo - quite interesting what's possible with time zones!

[tenter]

Hi @all,

I took a short look at the problem and I don't think that it's possible to implement your desired behavior on the product side. The used method is not even API as of now.

Couldn't you implement a render template that encapsulates rendering of your date? And in there, use an optional configuration for the date?

Regards,

Hannes

[tlegat]

Hey there,

I guess that we'll need to add this wrapper. Though that isn't nice and should be documented at least because it's a special case one wouldn't expect.

By the way, the used method ain't API of now but exists for a long time (as I found it here in a seven-year old post: Re: CMS_INPUT_DATE mit aktuellem Datum vorbelegen ) and why would you want to walk the whole version history to get the inital one's date? So maybe, as a feature request, add it to the API.

[betinajessen]

I see that Burmese years are an option for the calendar appearance but not Thai. It is 543 years greater than the Gregorian calendar. Could we make this a reality? Right now I am working  2023 calendar with holidays around it with the attached XLS calculation but it would be nice to have the widget.