Something up with the Date() functions in Duet?
GregG
Just some guy...
I have a little bit of code that uses the standard Date java stuff like this example:
Then whenever I toss the duet module a command string it will throw back a string like this:
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?
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?
Comments
-
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.
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums