JiBX is not ready to work with xsd:date XML type

And here is the patch for this problem: it's the validateDate(String text) which is confused that the text is longer than it expects due to timezone at the end. So the only we need is to change the next line in validateDate():
int split = text.length() - 6;
to be:
int split = minc - 6;

Dennis, please check this change and incorporate it into JiBX code.

Have you tried this with 1.1.6, Michael? I corrected the parsing issue as part of the 1.1.6 updates, and as far as I know there is no longer a problem. Though exactly how this should work is always a problem, given the disconnect between Java and schema date/time types.

The built-in formats defined by JiBX are listed on the "Conversions" page, http://jibx.sourceforge.net/details/conversions.html The schema xs:date representation is used by default for objects of type java.sql.Date, since this is the nearest Java equivalent.

In fact, that was only half of the solution. After the change described above there still exists problem of serializing correct date in any timezone: currently Utility.serializeDate(Date) converts date 1 Jan 2008 00h:00m:00s UTC+1 to "2008-12-31" which is not correct...

Here is my replacement for 1.1.5's serializeDate:

public static String serializeDate(Date date) {
StringBuffer sb = new StringBuffer();

Calendar c = new GregorianCalendar();
c.setTime(date);

String s;

int year = c.get(Calendar.YEAR);
if (year < 0)

s = "" + year;
addPrefix(sb, s, 4, '0');
sb.append(s);

sb.append('-');

s = "" + (1 + c.get(Calendar.MONTH));
addPrefix(sb, s, 2, '0');
sb.append(s);

sb.append('-');

s = "" + c.get(Calendar.DAY_OF_MONTH);
addPrefix(sb, s, 2, '0');
sb.append(s);

int offset = c.get(Calendar.ZONE_OFFSET) + c.get(Calendar.DST_OFFSET);
if (offset >= 0)

else

s = "" + (int) (offset/3600000);
addPrefix(sb, s, 2, '0');
sb.append(s);

sb.append(':');

s = "" + (int) ((offset%3600000)/60000);
addPrefix(sb, s, 2, '0');
sb.append(s);

return sb.toString();
}

private static void addPrefix(StringBuffer sb, String mainStr, int size, char fillement)
{
for (int l=mainStr.length(); l<size; ++l)

}

Actually i just found that you've released the 1.1.6 just a week ago. I will try it. Are both problems (one in serializeDate() and other in deserializeDare() fixed?

Unfortunately the serialization side of the problem is still there in 1.1.6/1.1.6a. I'll get this fixed for the upcoming 1.2 beta release.
I think the approach I'll use is to convert to the current date in UTC (and use the Z suffix).

The Java Calendar-based code is a horrible mess, and rarely works well for XML processing. In this case it may be what many people expect to have happen, though, so I can perhaps provide the Calendar-based serializer and deserializer as an alternative format. But what would you suggest the deserializer should do? Unless you happen to be in the same timezone as the originator of the XML, when you deserialize a date value with time zone you'll get a java.util.Date which may not represent the same day. That's why I think always using UTC makes much more sense.

On second thought, for xsd:Date it probably makes the most sense to always have it without a timezone specification. That way it can always be converted to midnight of the given date in local time (which is essentially how this works now when using the java.sql.Date deserializer).

So perhaps my default approach should be to serialize the local date without timezone specification, then ignore timezone specifications on an input value and deserialize the date to the local timezone. But if there are other alternative conversions which you think make sense I can implement them as alternative formats.

Just checked - there is no more problem with deserialization in 1.1.6, but the problem with serializing 31 of December instead of 1st of January is still there...

What about how it should work - in my opinion by default the serialization should be done in local timezone with or without appending that timezone to the end of the string. The deserialization should ignore the timezone specifiend in the string and use local one instead.

Also probably you should look into other datamapping frameworks. And if there are some general conventions about this problem, then you probably should also use that one. Anyway, if developers can somehow manage and customize the process of Date (un)marshaling, that would be nice. Since currently it is only possible to choose a serializer/deserializer, so at least a few serializer-deserializer methods for most friquenlty used conventions should be present in JiBX by default IMHO.

I've added support for the Joda date/time library, which provides more complete representations than the standard Java classes, and have also implemented a selection of conversions so that you can easily chose the way to handle time zones. That should take care of it.

Dennis,
I still face this issue.

These are the steps I did
1. Took latest release( 1.2.2)
2. Ran Codegen tool to generate default binding/java classes from schema.
3. Ran Binding compiler
4. Ran my test program and it still gave me same problem.

Do I need to do something else?
Best Regards,
Rohit