Uniface User Forum

When we display date time data on our web-page, we have a requirement to remove the seconds, but to preserve the browser locale date format if possible. 

'Raw' date time fields appear to display oddly (as UDT format with a 'T' between the date and time etc). 

How can we code a display format for date/time fields in a DSP which shows them in browser locale $NLS short_datim format? 

Everything we've tried has given poor results, I'm sure this must be simple, and we're just missing it. 

Thanks

Iain

Hi Iain, I think you want a field layout something like DIS($NLS(SHORT, DATIM)) along with setting $webinfo("locale") (read the documentation below as you have to do it in a specific place + you also may need to upgrade to a newer patch if you're using an older patch level): https://documentation.uniface.com/10/uniface/proc/reference/ProcFunctions/_webinfo_Locale.htm

https://documentation.uniface.com/10/uniface/development/reference/fieldDefinitions/displayFormatsDateTime.htm

Regards,

David

Documentation link for different possible ways to format date time in DSP- https://documentation.uniface.com/10/uniface/development/reference/fieldDefinitions/displayFormatsDateTime.htm

As per your requirement if you set the field layout property as "DIS($NLS(SHORT, DATIM))” or  "DIS($NLS(SHORT)) then you should get your desired output.

Note:- For locale you need to follow steps mentioned by <ac:link><ri:user ri:userkey="2c90b2b65af5caac015b1f029e73019f"></ri:user></ac:link> in the above comment. 

Hmm, I've tried a dinky dsp with a default date field, and a field set to DIS($NLS(SHORT,DATIM))

They display as follows. 

Default date format.     31/03/2021 12:12:42

NLS date format    2021-03-31 12:12

What I want:- 31/03/2021 12:12

$nlslocale and $webinfo("Locale") are both blank.

I want to identify the locale of the CLIENT web browser and display the dates as appropriate to the end user. The examples given appear to be to override the client locale with the server locale. I also don't know why the NLS one is year first. I'd expect either day or month first (UK/US). 

How do I identify the locale of the client machine so as to set the $nlslocale to the correct one? 

So, if I deliberately set the $nlslocale in the preActivate to en_GB or en_US, the $NLS date formats as expected. Therefore it appears what I need is some way of working out what to set $nlslocale to, based on where the client is sitting. (I.e. the locale of their machine.)

Is there something I could query in the $webinfo (or elsewhere) to find out the browser settings for locale?

Hello Lain,

You can follow the uniface document https://documentation.uniface.com/10/uniface/proc/reference/ProcFunctions/_nlslocale.htm to identify the locale based on the client web browser.

$nlslocale = $item("accept-language", $webinfo("httpRequestHeaders"))

For specific date time format with $nls you can set field layout as "DIS($NLS(dd/mm/yyyy hh:nn))"

Hope this will help you 🙂

Regards,

Bharti

Hmm, that returns the string "en-GB,en-US;q=0.9,en;q=0.8" but I think I can parse the locale out from there. 

.... 

Seems I can. That appears to be working. 

And then I hit the problem I remember having with $nlslocale. 

If you ever use "%%localvariable%%%" to build data to pass back and forth, it suddenly starts getting commas in it (for values > 999). 

So a piece of code which uses :-

"%%p_date[Y]%%%-%%p_date[M]%%%-%%p_date[D]%%%" 

to return a date for inclusion in a sql script, suddenly returns "2,020-01-04" and screws up. 

I've fixed this one by replacing with a formatted global variable, but who knows what other logic bombs are out there waiting for me. 

ISTR the last time I tried $nlslocale, I accidentally put it in the IDF asn, and the whole of V9 collapsed because they were doing this to get field indirection using numbers, which is why I swore off the thing in the first place. 

And found another one, which doesn't show up in base testing. 

Passing an ID field (i4) in a params string as component.operation("ID=%%idfield%%%") works where your database is small and the IDs are < 999 (as is the case with most of our test databases), but fails in production where the IDs are > 999. 

Most of our operations (particularly legacy ones) use inparams and outparams as two strings, due to the issues with the uobj and uar in earlier versions storing signatures. So we use this a LOT.

I am going to have to work out how to use the $nslocale in a VERY tight band around the output back to the web page to prevent these things from tripping me up. 

Never simple, is it? 

Iain