[netcdf-java] DateUtil vs DateUnit time zone?

Hello all

The methods from ucar.nc2.units.DateUnit seem to assume a GMT timezone, while the methods in ucar.unidata.util.DateUtil seem to expect a mix of GMT timezone (getTimeAsISO8601, roundByDay, parseRelative) or local time zone (parse, findFormatter). Is it the intended working? If so, maybe it would be worth to document in the javadoc?

As a side note, looking at the DateUtil code, I saw a few details that may be worth to mention. Around lines 255 and 450 there is code like below:

        if ((lastSdf != null)&&  (lengthLastDate == dateString.length())) {
            try {
                synchronized (lastSdf) {
                    lastSdf.parse(dateString);
                    return lastSdf;
                }
            } catch (ParseException pe) {}
        }


This code is actually unsafe, since there is no guarantee that the lastSdf and lengthLastDate field values are not modified between the if statement, the synchronized statement and the call to the parse method (those fields are modified elsewhere in unsynchronized code). A partial fix would be declare the lastSdf field as volatile and add the following line before the above code:

        final SimpleDateFormat lastSdf = this.lastSdf;


We still have a synchronization hole with lengthLastDate however. Note also that the following code (line 168):

        Calendar cal = Calendar.getInstance(TIMEZONE_GMT);
        cal.setTimeInMillis(time);
        Date curSysDate = cal.getTime();


Could be replaced by a plain new Date(time), since the Date(long) constructor is timezone-insensitive. I mention just for information (not asking for changes).

    Martin



  • 2012 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: