views:

176

answers:

2

I have an application that runs on both C# .Net and Java. Two entirely separate but identical code bases. The problem Im having is formatting date and numbers.

For example: A user running the .Net variant is inputting a date and a format string. The 26th of April 1986 is formatted 1986-04-26. The actual date, along with the format string, is serialized to an XML file. Later another user running the Java variant opens said XML file and looks at the date. I want them to look the same.

Whats the best approach here? There doesnt seem to be a one-to-one mapping between Java and .Nets format strings. Should I limit the possible formats to a selection I know I can represent fully in both .Net and Java?

+2  A: 

Use a Standard Format. Since XML defines a Date format itself, you exactly this. See http://www.w3schools.com/Schema/schema_dtypes_date.asp for more info. A Date would look like 2010-12-24, and a datetime like 2010-12-24T23:59.

And since Java and .NET both have their own date format classes, you just should decide to use one. There is no "default" date format, however, if you use the Java DateFormat class, the date will be printed using the detected platform locale. And since this is known to be changable, you have to speficify the format yourself anyway.

Daniel
This is similar to my current approach. I make Java mimic .Net by reading .Net format strings and behaving accordingly. However, since the user has the option to write their own, custom, .format strings (.Net flavor) Im struggling to figure out a proper way to map them. If I understand you correctly, the user should never input .Net format strings rather some 3rd party standard, which both .Net and Java, through a class I write, understands?
mizipzor
Yes. Another way would be to chain multiple parse attempts with different string formats in likeliness order. IMHO is the performance loss for not using the right parser at once neglectable. I have already written a function parseAnyDate() in java, which tries 20 different formats, and use it for user date input to be capable to handle nearly everything the user might think of.You can push this even further by first tokenizing the date and try to parse any strings like "Sep" for "September", try to find 4 digit columns for the year and two digit columns for a day of month. Up to you.
Daniel
+3  A: 

I would strongly recommend not to write any parser and writer yourself, but to rely on existing libraries and standards. As you want to write/read to/from an XML file I would strongly recommend using the standard for date-times there: ISO 8601.

Java:

You could use Joda Time, a library that supports the ISO 8601. The format weekDateTimeNoMillis (see doc) provides just everything you would need if you want to keep the possibility of eventually storing time, too:

  • Date
  • Time
  • Timezone (either a 'Z' for UTC, or +/-HH:MM for a different time zone).

date (see doc) may be the right thing, if you dont ever want to store time info. It is of the format yyyy-MM-dd (notice: if you perform a string sort algorithm it will sort it correctly by date)

C#:

The .net framework already provides a ISO 8601 writer and parser: DateTime.UtcNow.ToString("s") will write the correct format yyyy-MM-ddTHH:mm:ss.

You see: you just have to decide for a format (only date, datetime or datetime with timezone) and use the respective tools in both languages and everything will go fine. If you dont specify the format exactly, strange things could happen: you cannot recognize 10-09-08 without knowing its format, is it:

  • 9th Aug 2010
  • 8th Sep 2010
  • 10th Sep 2008
  • 9th Oct 2008
  • ... ?

You/the parser just cant know.

Philip Daubmeier
The right answer of course is 10th September, 1908 :)
Esko
*This* is exactly what I needed; a common and well defined format with parsers ready to be used in both languages. Although Joda Time wont work (since we cant apply the apache license to our project). But at least I have a standard to search for now, will investigate first thing tomorrow. Thanks. :)
mizipzor