This has been driving me crazy for a long time while working on the runtime solution I plan to market later this year: what would be the "best" date format to code it in for data input? I'd like to market it first in the U.S. and Canada, then worldwide.

 

Here's the thing...

 

Here in the U.S., we use the MM-DD-YYYY format; our friends to the north use both DD-MM-YYYY ( as in 03-MAR-2013) and ISO 8601's YYYY-MM-DD format; other nations have their own or similar formats. What I want to avoid is having to create different versions of the same runtime for use in different countries--that would be a headache to maintain.

 

Two problems right off the bat are that it's a runtime so users can't customize date input fields to whatever style they want. The second is that the date fields inherit the date format the "master" file is set at so, for example, if I set my Mac's and PC's preferred date format to MM-DD-YYYY, that's what gets encoded into the runtime (as far as I can tell) as the default date format.

 

What I've done so far is create a global date format field so users can print lists and reports in the date format of their choice (which they choose from an editable value list). However, when it comes to data input...? I suppose ideally I would set every date field to ISO 8601's standard since that is the standard everyone is suppose to follow/use, but I don't want to annoy my largest market share (Americans) with a date format they're unaccustomed to.

 

As always, your input/help is appreciated!

 

Cheers,

Rich

Wow. I have never created a runtime. I did not know that you couldn't set it to use OS settings upon startup. This seems a critical omission for FM.

I create runtimes all the time.. and offer it as a standalone runtime solution..

as a matter.. i suggest loading it on a memory stick... if you wish..

 

You might need to deal with UTC time zones too.. even US driving across country finding a camp

When I speak today's date I say "June 8,2014" so I always use this as my date format (MM/DD/YYYY). I see no reason why you wouldn't choose a given format and specify it in your solution via information provided on the layout or via tool tips or both.

You really oughta get out more, Rick.     It's a big world out there, not everyone speaks English, and even amongst those who do, not everyone speaks the dates as you do - and certainly does not write them the way you do. You can't impose your standards on others (esp. if they are paying clients), tool tip or no tool tip.

Michael,

 

       I get your point and I know "it's a big world out there". My post was a suggestion (if not a great one). Since the world is such a big place it would also make sense to localize not just date formats but languages as well. I assume some developers might do this but most don't. If a solution is written in one language, in this case let's assume English, I would say it's not unreasonable to specify a date format or to, as an alternative, use System Formats as the default. If a person is designing a solution for a particular client then all formats should be as requested by the client. However if designing an "off the shelf" solution I believe the issues are different and perhaps not quite as straightforward. Then again, I'm a rank amateur.

Since the world is such a big place it would also make sense to localize not just date formats but languages as well.

 

True, the problem is wider than just system formats. But that's no reason to give up on using system formats. It might be acceptable for a German-speaking person to use a solution with English labels - but I don't think they will find it acceptable to be forced to enter dates in a format that's foreign to them (and different from the one they use daily to enter dates in other applications on their computer - so they can't even copy/paste a date between programs ), or enter numbers using decimal point instead of decimal comma.

 

This thread is more than a year old, and I don't have the time to test this now - but I can't help wondering if the basic premise of the OP is true.

"This thread is more than a year old,"

 

Yes! I hadn't noticed that since the thread came up as new content.

I hadn't noticed that

 

Because of the date format...

Ha! Probably.