Timezone-awareness of DATE PrimitiveValueType

[bruno]

Currently the DATE PrimitiveValueType? is based on the java.util.Date class, which has no awareness of timezones.

The preferred way of storing dates (times, datetimes) is to normalize them to the UTC timezone.

We could of course take the assumption that the provided j.u.Date object is in UTC, but:

• not sure but this might be clumsy to work with in combination with other Java APIs (e.g. upon conversion to a Calendar object). In general it moves responsibility and braineffort towards the user.
• we could consider using jodatime api, see ​http://joda-time.sourceforge.net/
• we could consider using ISO-8601 string representation (avoid dependency on jodatime in the api, but validation of correctness of the string will happen late).

Personally leaning towards jodatime.

Also: what date/time related PrimitiveValueTypes? should we have (date, time, datetime)? Up to what precision should they work (seconds, millis) ?

[bruno]

(In [4064]) * Separating primitive value type DATE into DATE and DATETIME. Make use of jodatime for representing dates and datetimes. Fixes #11.

• Do automatic table creation in response to TableNotFoundException? instead of IOException.

[bruno]

The original subject of this issue was not really correct: java.util.Date always represents a time instant in UTC.

The problem with java.util.Date is not so much for datetime fields as for date fields. Timezone-less dates can be represented by jodatime's LocalDate? class.

Still, not sure if we really need jodatime for this (as a repository api dependency), rather than an object defined by us. Needs more thinking. Opinions welcome.

The current jodatime usage does not persist the chronology, not sure how important this is.

[bruno]

pro jodatime use arguments:

• avoids the need to do an extra conversion to jodatime when you want to do something (formatting, calculation, ...) with the date or datetime. And the same for the other direction.
• we make the choice for jodatime for our users, so that they don't have to think about that anymore

[bruno]

Decided the jodatime dependency is no problem.

Since the chronology is not visible in the exchanged dates/datetimes, I suppose it is not important to store it, but that it is rather to the user who wants to do date manipulations to decide which chronology to use.