Parsing date fields in a DBF file implicitely with the local time zone imposes several problems, when the time zone in which the DBF was created differs from the local one:
(1) If you want the correct Unix time stamp, you have to convert the returned Calendar to a datetime string, and then back to a calendar, this time using the correct time zone.
(2) When the local time zone exhibits winter and summer time, and the "DBF creation time zone" doesn't, then you get WRONG results twice a year, even when performing the workaround described above in (1).
I know this sounds kind of unimportant, but we have exactly this situation here at our company. Our customers here in Germany (Winter: UTC+1, Summer: UTC+2) are running wind plants somewhere in Taiwan (UTC+7 all year). And they are becoming really angry at the slightest data loss at all.
so is your problem with the getCalendar method in the date field class?
can you provide an example on how the method should work?
Like this, I thought:
public class DateField
{
...
Calendar getCalendar(java.util.TimeZone timeZone)
{
...
Calendar result = Calendar.getInstance(timeZone);
// I guess, the remaining code can stay the way it is.
return result;
}
}
You could provide this as an overloaded method, i.e., provide the method as it is now, without time zone, and additionally provide this one.
I will be away for three weeks now (regarding the delay of answers to further comments).
Cheers, Stefan
in release 20140320