Hi
If I set my power management scheduling times, they are all reset when I reopen the power management dialog.
Beta 18, watch the attached quicktime where I set times then OK and reopen the dialog.
(FWIW We tried to deal with this a few builds ago by setting the data directly in the database, but the values were a little odd, not sure if timezoning has anything to do with the problem)
cheers,
grant
SettingSchedulingProblem.mov (737 KB)
Hey Grant,
In the movie, when you are initially setting the times you have the Daytime group selected. Then after closing and opening the dialog again, you have the Nighttime group selected. There is definitely a sort bug with the power management groups (they should always be in ascending order), but I can’t reproduce the scheduling time bug. Can you double check the Daylight group to see if the times were actually saved or not?
Thanks!
Ha.
But it makes no difference, check the attached where I try again to demonstrate the problem.
cheers,
grant
SettingSchedulingProblem_02.mov (694 KB)
I think we figured out the issue. There was a disconnect between the selected group in the list on the left and the actual group settings shown on the right. So it was possible for one group’s settings to overwrite another. We have fixed this disconnect, and I can’t seem to reproduce the problem anymore.
We’ll include this fix in beta 19, and hopefully that resolves this issue once and for all! 
In that video I modified both the groups that have been created - but I’ll obviously test the new build when it comes out and let you know.
thanks,
grant
If I set my machines Time Zone Settings to Coordinated Universal Time, I can set the power management scheduling options.
if I set my time zone back to Melbourne Australia (+10), when I then set a value it clears that value.
It seems to be displaying times that are translated by my timezone too which could be a problem as we have daylight savings here (ie the times I set earlier display differently depending on what I set my local timezone to), and I imagine the power management timings might be an our out once we go into or out of DST. So, after going back to my own timezone any time value I set is zero’d out, it’s no doubt translating my local time to it’s local time and things are going wrong.
I checked on mongo, and it always stores as UTC - so I would guess that monitor is messing up the timezone calls somehow; I would expect that if I entered 2am it would translate and store it as 2am UTC in the database, so when it is translated back to local time it’ll be 2am regardless of what my local timezone/daylight savings state is set to.
cheers,
grant
I think you hit the nail on the head here. The way we do Dates/Times just about everywhere in the Monitor is to:
A) Always get the current time from the MongoDB server (cached as an offset of the current machine’s clock)
B) Always store as UTC
C) Always convert back to local timezones for display purposes
This works fine for most things, and even should work fine with DST (NA already switched over to DST, so we’ve had a chance to work through those bugs already ), but as you’ve been experiencing this gets weird when setting time ranges on a specific day of the week, like in Power Management.
We’ll change this to ignore timezones, and once Pulse reaches those times (in whatever timezone Pulse is in), Power Management will trigger.
Cheers,