The implementation of showing datetime for raid reset in the tooltip is a bit hacky - could use refactoring to a more stable/intuitive solution.

Issue:
The API returns time left until reset as UNIX time in seconds. The UI seems to prefer displaying this as days:hours:minutes:seconds left until reset. I prefer displaying this instead as a fixed calendar date when reset will occur.

Right now this is displayed by taking the current time in UNIX time (seconds) and adding the time until reset (seconds) and then formating this in dateTime format. This get recalculated every time the tooltip functions gets called (every time the user hovers over the panel addon to view the tooltip).

The main issue is that the time until reset keeps shifting ahead from the time the addon get's initialized (login) or reloaded (loading screen).

Another potential issue is that if the user keeps the tooltip open for over 1 min the time will start to shift. since it only gets updated when displayed. Minor issue since you usually don't keep it open for that long.

Update:
I've figured out why the time keeps shifting. Every update call of the tooltip I'm relying upon the return variable reset of the API call GetSavedInstanceInfo(index), which I add to the current time and format to display the final calendar date and time in the Tooltip for each reset. It seems the reset value gets cached, and not updated on new calls of GetSavedInstanceInfo(index) - thus the problems I've had with the time starting to shift by several minutes. reset gets refreshed after relog, ui-reload or any loading screen.

I've noticed this cache getting cleared naturally after about 10-30 min- probably by some other event that gets fired semi-regularly.

The solution for the moment (v.1.0.0) is not very elegant but it is working. I force the minute value back to 0 every update to negate the time shift. However this is relying upon the assumption that the cache always will be cleared naturally before 60 min has elapsed since the last clear - if this does not happen the user will experience the bug of the reset time being one or more hours ahead until the next ui-reload.

If the above becomes a problem, a solution could be to find an API call that clears this cache, keep a countdown and run this cache clearing call only if the ui has not been reset for close to 60 min, since it's obviously being cached to limit client calls to the server.

Following the latest update the problem with time shift of reset time was fixed, but the issue remains that the way this is implemented is not that efficient or succinct - a refactor could still be useful. Removing the bug tag of this issue.

I as player, who has a main raid and sometimes a random raid, want to see the next Reset of 20er raids (ZG, AQ20). Also if i have a clear ID i want to see, if i can use actual ID with a random group before my next main raid occurs.

I as player, who has a main raid and sometimes a random raid, want to see the next Reset of 20er raids (ZG, AQ20). Also if i have a clear ID i want to see, if i can use actual ID with a random group before my next main raid occurs.

Moved this feature request into it's own thread