local now = time() ;
return time(date("!*t")) + difftime(now, time(date("!*t", now) )) ;
and it is returning the correct time, in seconds, for all timezones on all realms at the same time.
all is good. or so i thought.
one issue i've consistently had is a memory leak that makes the memory for my addon oscillate from 3mb to 10mb and back. this is quite annoying. after an all day dew fueled bug hunt, i surrounded the leak to this function.
the issue is that the function returns a table, which is needed by 'time' for the calculations (if you have a better/slicker way, please let me know). and since it returns a table, that i do not supply... it just leaks.
the docs suggest the table is a system table... which would make me think there would be no leak. no such luck.
try it yourself. put it in a tight loop and let it rock.
-- Calculate the timezone offset from time(), which should fixed for a given client
local now = time()
local delta = time(date("!*t", now)) - now
-- Calculate the UTC time, based on time()
return time() - delta
well, that's the thing... many users have the wrong timezone set on their machine and i end up walking them through changing it. with the old utc_time, it would pick up the new timezone on the next date call.
i've added a cmdline option they can type that would pull the date on the next utc_time (just clearing the fields). it'll leak the tables, but that's acceptable as it rarely happens.
of course, they could also do a /reload
i've already verified the update works from australia to the east coast with data generated in the various realms between (using normal time would result in varying timestamps and the data would 'expire' relative to each other... hence the use of utc_time). memory is no longer leaking and the addon's memory usage is stable
local tz, tzdiff;
if tz ~= date("%z") then
local utc, here = date("!*t"), date("*t");
here.isdst = false;
tzdiff = difftime(time(here), time(utc));
tz = date("%z");
I did a quick test that actually led me to change the isdst flag as this would otherwise generate wrong output (you should consider that in your code too, even if you don't use mine)
After the first run you don't get any new tables, and if the timezone ever changes, it should get updated automatically