This doesn't address the crux question: What set %date% itself? Was it an event? Were the two events the same, or different events. %date% is actually the date reported on the last event for that rule. It could be that it is being set from two different sources, or two different pieces of code, and this could explain the difference. Need to know this to track down what could be causing this.
GVDate is set by this rule that I use to set my GVWeekday. It runs at 00.05 every day. I added the set GVDate line to it yesterday for testing purposes.
GVDate1 is set by this rule that I initially set up today to run at 9.15am.
Weirdly (there is a lot of "weirdly" in all this I'm afraid) when it ran automatically at 9.15, the GVDate1 value stayed at the value I set for it when I created it, which was 'test'. The subsequent runs of it were me manually running the rule from the rule screen. It was only on the last event that GVDate1 was actually set and then it was correctly set to the UK format date you can see in the GV list posted above. These are the logs for that rule.
I did find one source of the discrepancy:
state.lastEvtDate = (new Date()).format("dd-MMM-yyyy", location.timeZone)
That is from hitting Done or Update Rule.
And this:
state.lastEvtDate = evt.date.format("MM/dd/yyyy", location.timeZone)
Which is how all events format the date.
Running the rule from the UI button should not change %date% unless the rule does certain things, including delays.
That's what I understood from what you said yesterday. So with regard to my "Test GVDate1" rule, it should only have been set at 9.15 (and would be in MM/dd/yyyy format) but the GV that was set to it's value only changed on one of the manual runs (as the format of the GV confirms being dd-MMM-yyyy format)
It feels to me that this has to be something to do with the change of month. Maybe it is because if you switch the month and date in the early part of the month you get a valid (albeit wrong) date ie 03/09 to 09/03 but at the end of a month 23/08 switched to 08/23 is invalid. As I said this was working OK for the last week in August but 1st of September screwed it.
Having read that back, that doesn't make sense either though because it fails the wrong way.
I'm just going to change it so that the format is dd-MMM-yyyy throughout. The rest I can't explain.
2 Likes
Me neither. It is very strange and confusing.
I've rebooted my hub in case there was some glitch somewhere and I've now set up 5 new string GVs for dates and 5 separate rules running at various times of the day to set them to %date%. I'll see what happens tomorrow after they have run
The reboot didn't help.It's 9th April in our house this morning according to the TTS - time is flying by!
This is the current state of my test GVs for date and the rules that created them. For some reason the one at 2am has left the date as yesterday and in a different format to the others. If I get the system to announce the GVs through TTS, GVDate2 is the only one in the correct format (albeit for yesterday) and says third of September twenty nineteen, the others all say ninth of April twenty nineteen.
The in-use by list is wrong for GVDate2 btw, it is only called by "set GVdate2 at 2am".
Could anyone else in the UK try to replicate these rules please to see if they get similar results and what happens when you TTS the results.
