FWD » Core Development » Database

In #7504-31 :

I also encountered a potential bug during import:

• I imported a .d file containing the value 01/01/1920 for a date column.
• After import, the stored value in the database was 1919-12-31 (disregarding the formatting), which indicates the date was altered during the import process.

I've created 10181a and and committed the fix to rev / 15992.

• instead of using the default jvm timezone that would alter the date, use UTC timezone.

Ovidiu, when you are available please take a look on the branch.

I am OK with the change because the UTC will leave the data unaffected by the TZ.

However, I think all occurrences of date.dateValue(TimeZone) might require rethinking and in relation, date.dateValue() as well. That is because the reverse operation (_getDate()) will return date instances created with TimeZone.getDefault() timzone (which is the default is null is used). So they are no longer pairing.

As a side-note, I still have a strong opinion that the date implementation is too complex. It should be timezone agnostic. In fact, the only data type which is supposed to be TZ aware is datetime-tz. We are not sure how this is store in OE, but the educated guess (based on OE direct compatibility with int, date aritmetic) is its representation as as simple as an int meaning then number of days passed since the epoch. Actually, we do something like this, but most operations involve a GregorianCalendar instance and TZ. I think there is a task for reimplement the date related types using the new (not so new any more) time API (LocalDate).

Thanks, Ovidiu.

What testing should be performed for this change?

Branch 10181a was merged into trunk on behalf of Lorian (ls) as rev. 16010 and archived.