Jump to content

Need help with choosing a date format for a runtime solution


This topic is 3580 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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

Link to comment
Share on other sites

  • 1 year later...

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This topic is 3580 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.