Replies

• allan Posts: 65,481Questions: 1Answers: 10,876 Site admin

  January 8 edited January 8

  Hi,

  Thanks for the feedback! At the moment, there are two ways of handling formatted dates:

  1. On the client-side. This involves setting field.displayFormat for the Editor field and a renderer for the DataTable column.
  2. On the server-side. In this case you just need to set field.format and also register the date/time type with DataTable.datetime.

  The DataTable date renderer can actually accept no arguments which means it will take the ISO8061 wire format, and display it in an automatically detected locale format.

  Perhaps what I need is a way for that automatic format to also work with Editor? It would probably need an option to tell it to use the automatically detected format. Everything on the wire would be ISO8601, which, personally I prefer working with, allowing the client-side to format it as needed per locale. Would that work better for you?

  I've focused on dates here, but numbers are similar.

  Allan
• resqonline Posts: 62Questions: 15Answers: 0

  January 8

  @allan thanks for commenting, I appreciate this. I know what the current handling is, which makes it extremely frustrating if you need to set it on a per field basis, especially when you have different tables and different editors and always have to remember to include the formatting.

  Using the locale would be the best solution, I agree. I recently updated the German translation json for my installation and found that the decimal "," was empty - and there I was wondering, why my tables didn't format numbers correctly... But the dates drove me nuts! Especially, when the SQL data included a time and I only wanted to display the date in the table, but of course keep the time in the actual data. And then there are all my Editor instances with lots of date fields, some of them with functions to check against some other date and so on.

  Date-times are even a pain when working in PHP, so I am wondering constantly about why this is and why there is no easy solution to this, probably because US format completely misses the logic of ordering the parts from lowest to highest or highest to lowest.
  I've only recently (in the last few years) found out, that Switzerland uses a different number format for thousand seperators - so I totally understand, why it's a complicated problem.

  If it would work with locale and I only have to set the format once as a default and not for every single field that needs the standard format, that would help a lot!
• allan Posts: 65,481Questions: 1Answers: 10,876 Site admin

  January 9

  But the dates drove me nuts! Especially, when the SQL data included a time and I only wanted to display the date in the table, but of course keep the time in the actual data.

  I can see editing just the date part of a datetime value being a pain. I did some work a little while back on -content searchDateTime to introduce a "mask" option so that it would allow searching, e.g. only on the date part of a datetime value. I will look at how I might be able to use something similar in Editor's datetime field.

  If you have a datetime value and you just want to display a localised formatted data, you can use DataTable.render.date() as the renderer for the column (no extra parameters needed, it will sort out the format itself).

  probably because US format completely misses the logic of ordering the parts from lowest to highest or highest to lowest

  I'm in the UK. The US format has never made sense to me .

  Personally I'm a big fan of the way the Swiss format numbers, have ' as the thousands separator makes a lot of sense - there is no ambiguity and I use it myself a lot.

  Perhaps a single locale setting is going to be the answer. With the renderers I've tried to have it auto detect the locale. The trick is to allow assumptions to be made (auto locale), but also to allow customisations, as it is never as simple as auto detect (e.g. many will do the formatting on the server-side).

  Allan