It is correct here. MAX 6.1.5 (32Bit) MacOS 10.8

Thanks. I'm running OSX 10.9.

I get correct date and time info with Max 5.1.8, 6.0.8, and 6.1.3. With 6.1.5 the time (and consequently the date) is aprox. 19 hours behind.

FWIW, with Max 6.1.3 32-bit on Mac OS 10.8.5 with my computer's clock synched to time.apple.com at 12:10:30 PST and with http://wwp.greenwichmeantime.com/ showing the time as December 7, 2013 at 08:10:30 GMT, my date object reported 12/6/2013 07:20:05. ?

So I checked and it seems i was running 6.1.5 in 64-bit. I changed it to 32 and it worked, i.e., i got a time and date that matched the system clock. I change it back to 64 and it continued to work. That looks like an initialization problem. Does 6.1.5 default to 64-bit because i don't remember changing that. However, if I run my clock patch, and close my notebook, when i open it the next morning the clock starts running again, but at the time displayed when the notebook was closed. Which makes me think that the date object references the system date on load but then runs its own internal clock... because it drifts relative to the system clock - i don't know how many days this patch has been running but it is currently 11 seconds ahead of the system and widening the gap. Currently running 6.1.6 32-bit OS X 10.9.

Yep, it's probably something like that... it may initialize once, but then not do so again after sleep, getting off by as much time as the computer was asleep, or something like that. It works fine here right after restarting Max.

Is there any fix or workaround for this issue? I am making an interactive clock patch but if the computer goes to sleep, the time will remain inaccurate unless I quit and relaunch Max. Closing and reopening my patch does not help as the entire application needs to be relaunched. Is there maybe a different object that will always reference the system's clock?

there is the [mxj now] object that comes with max i think, if you are willing to have java loaded with your patch