Something up with the Date() functions in Duet?

GregG

I have a little bit of code that uses the standard Date java stuff like this example:

import java.util.Date;

public class DateTest extends Utility {

   public void handleAdvancedEvent(Event obj) {
      Date now = new Date();
      log(INFO, "Date/Time = " + now);
   }
   // Assume rest of standard module here...
}

Then whenever I toss the duet module a command string it will throw back a string like this:

(0000274031) com.rsd.datetest.dr3_0_1.DateTest: Date/Time = Tue Feb 10 12:25:18 GMT 2009

However, when I change the time zone in the clock manager, it changes this time value to reflect local time, but still leaves the GMT tag on it, which seems incorrect, since Date() should always be a UTC absolute value.

So solving the problem for Duet by setting the clock manager to UTC then messes up the local netlinx time for things like touch panels etc.

Anyone have any ideas here?

HARMAN_shane-a-roo

Currently, the Clock Mgr information is not tied into any Java resource facilities. The Time Zone setting for the Clock Mgr is only used for calculating delta off of UTC from the NIST server. This then sets the real-time clock of the OS which is not time-zone specific. This time would/could then be propagated to the panels which are also not zone specific. Said another way, the Master does not store internal time in GMT and perform the time-zone delta calculation each time date/time is retrieved. It does it once when the time is retrieved from the NIST server and sets the internal clock based on the correct local time.

But this is not the way Java works. Java would have a specific locale set most likely causing a delta calculation from the internal clock time (which would have to be stored as GMT) each time a date/time value is retrieved. The master currently sets no locale and it is defaulting to GMT (as you've noticed in your printouts)

I will make a note to see if this can possibly be rectified in a future release, but I can't be certain because the two methodologies (AMX=store in local time, Java=store in GMT) are opposite, and changing the master to store in GMT might adversely affect other AMX devices.