International date / time / number formats management?
Hi,
I have 3 basic questions:
1/ Time management: How do I change the default time format for a prototype ? And how can I adjust the time format of a prototype via an app setting?
2/ Date management: How do I change the default date format for a prototype ? And how can I adjust the date format of a prototype via an app setting?
3/ Numbers display: How to change the default number format for a prototype and field by field? How can I adjust the format via an app setting? And generally speaking, how can I apply the pattern I want for a specific field, like for phone numbers, credit cards numbers, etc.?
It applies to:
- the way dates are displayed in input fields (not text fields)
(dd/mm/yyyy, yyyy/mm/dd, mm/dd/yyyy, d mmm yyyy, etc.)
- the way times are displayed in input fields and like on the status bar
(hh:mm, h:mm AM/PM, etc.)
- the way the date selection tool is displayed during simulations
(day|month|year or year|month|day or month|day|year)
- the way numbers are displayed in input fields
(0 000,00, 0,000.00, 0, 0,0, 0.0, 00 00 00 00 00, 0000 0000 0000 0000 000, etc.)
For information, regarding dates, I've seen this tutorial...
https://www.justinmind.com/support/how-to-change-the-date-format-in-your-interactive-prototypes/
But this is really not what I need. I'm talking about input fields and date/time selection tools during simulations.
Thanks!
???
Why has the status been switched to "Answered"?
There's not even the beginning of an answer!
Unless I should consider this switch as the acknowledgement by the JIM team that JIM is unable to adjust to any time, date or number format to anything else than the US ones?
FYI...
Countries using 12h clock...
Countries using MM/DD/YY date format...
The USA is nearly alone (in violet)
https://en.wikipedia.org/wiki/Date_format_by_country
=> The formats used in the USA are most the exception.
Most of the time anywhere else in the world, we use different formats than the US ones.
???
Why has the status been switched to "Answered"?
There's not even the beginning of an answer!
Unless I should consider this switch as the acknowledgement by the JIM team that JIM is unable to adjust to any time, date or number format to anything else than the US ones?
FYI...
Countries using 12h clock...
Countries using MM/DD/YY date format...
The USA is nearly alone (in violet)
https://en.wikipedia.org/wiki/Date_format_by_country
=> The formats used in the USA are most the exception.
Most of the time anywhere else in the world, we use different formats than the US ones.
Oops! We thought we answered this a long time ago, but our response was actually only published internally rather than as a comment that you can see. We originally said:
Unfortunately, we only have one format for date/ hour inputs. As a workaround, you could add an "OnChange" event into the input data so when the changes are applied to the date table you can apply the change of format through an "On set value" (as detailed at the tutorial).
Oops! We thought we answered this a long time ago, but our response was actually only published internally rather than as a comment that you can see. We originally said:
Unfortunately, we only have one format for date/ hour inputs. As a workaround, you could add an "OnChange" event into the input data so when the changes are applied to the date table you can apply the change of format through an "On set value" (as detailed at the tutorial).
Thanks for the answer.
At least, the answer is clear for date/time.
So will you add this in your roadmap to quickly add this improvement?
As if your market is the US only, then ok you're fine.
But if you want to boost your sales worldwide, it's an important basic feature missing.
If I take the example of Europe and the majority of the world:
- we don't use 12h clock but 24h clock
- we don't use MM/DD/YY format but DD/MM/YY format
- weeks don't start on Sundays but on Mondays
- numbers format is not 0,000.00 but 0 000,00
- currencies format is not $ 000 but 000 $
- etc., etc
So most developers can accept JIM is not translated in any other language than English as what's important is the prototype. Unless you really don't speak English, it should not be an issue.
But prototypes have to match their market specifications. Otherwise, not only it messes up the quality of the prototypes designs, not only prototypes can't respect the companies or customers specifications, but it even leads to malfunction ( <-not sure it's the appropriate word in English, sorry)
Example: try to add a date field in a JIM prototype, set a default date, then run this prototype on an iPhone set-up with any non US format (take even the UK one is you want) and you will observe that your default date will never be displayed as once on the iPhone, the used date format becomes iOS one and in this context, the OS doesn't recognize something like 02/25/2018 as a date.
At last, what about numbers inputs?
There's no answer.
How can we set number formats? (separators, number of decimals, currencies, credit card format, phone format, etc. etc.)
Thanks for the answer.
At least, the answer is clear for date/time.
So will you add this in your roadmap to quickly add this improvement?
As if your market is the US only, then ok you're fine.
But if you want to boost your sales worldwide, it's an important basic feature missing.
If I take the example of Europe and the majority of the world:
- we don't use 12h clock but 24h clock
- we don't use MM/DD/YY format but DD/MM/YY format
- weeks don't start on Sundays but on Mondays
- numbers format is not 0,000.00 but 0 000,00
- currencies format is not $ 000 but 000 $
- etc., etc
So most developers can accept JIM is not translated in any other language than English as what's important is the prototype. Unless you really don't speak English, it should not be an issue.
But prototypes have to match their market specifications. Otherwise, not only it messes up the quality of the prototypes designs, not only prototypes can't respect the companies or customers specifications, but it even leads to malfunction ( <-not sure it's the appropriate word in English, sorry)
Example: try to add a date field in a JIM prototype, set a default date, then run this prototype on an iPhone set-up with any non US format (take even the UK one is you want) and you will observe that your default date will never be displayed as once on the iPhone, the used date format becomes iOS one and in this context, the OS doesn't recognize something like 02/25/2018 as a date.
At last, what about numbers inputs?
There's no answer.
How can we set number formats? (separators, number of decimals, currencies, credit card format, phone format, etc. etc.)
Any answers to my 2 questions ?
- will you add this in your roadmap to quickly add this improvement?
- what about numbers inputs?
Any answers to my 2 questions ?
- will you add this in your roadmap to quickly add this improvement?
- what about numbers inputs?
Hello,
This feature has been added in the newest version of Justinmind.
Hello,
This feature has been added in the newest version of Justinmind.
Replies have been locked on this page!