As part of my morning alarm routine I have TTS announce the date using the %date% string. I'm in the UK so use the European date format.
I've been using it for a few weeks and it's all been fine. Yesterday it announced "the 31st of August" correctly, but today it announced "the 9th of January".
It is now a few hours later and testing it again it has now correctly announced "the 1st of September".
I haven't updated or rebooted my hub in the last 24 hours and my location settings are all correct. The date format is showing ok on dashboards. The only thing I can see is that the format of the date in the current hub time is the US format, but that is now and the date is being spoken correctly now anyway.
It sounds to me like an Alexa Poly problem. The in the settings for your hub isn't dependent on where you are located. It's in "universal" format used by almost all date/time systems. YYYY-MM-dd. It's the same for me here in the US.
I work on a medical device system and all dates when sent from one system to another are translated into that date format so that both systems know exactly what the date is without having to ask the format. It also goes from Number that would change the least frequent to the number that would change the most frequent. Makes it a lot easier to sort numbers.
Do you have the %date% stored in a variable or just sent directly to TTS? Because here in the US, %date% still results in 01-Sep-2019. If yours is the same, then it isn't a Hubitat issue, that would always be formatted the same. It sounds like when Amazon Poly was creating your TTS message, it couldn't figure out what it was supposed to use so it just said what it thought it should. When i use %date% though I get "September first twenty nineteen" spoken out completely. You'rs saying you just get First September?
And you were using Hubitat TTS (which is Amazon Poly)? I would suspect it was a futz in it rather than in Hubitat. I've never seen %date% spit out the wrong date but I've had amazon poly screw up a lot.
Well, if it happens again, see if you can get to it to grab the logs. But like I said, I've never seen %date% spit out something in the wrong format and I wasn't able to find any other threads about someone reporting the same thing. But how many times has Amazon Poly mispronounced something? Happens a lot.
This morning the alarm routine announced "The 9th of February Twenty Nineteen" which seems to be based on the correct date (which is 02/09/2019 in UK format) but with date and month switched. This is what it did yesterday.
However if I run a test rule to send %date% to the same speaker it announces "The 1st of September Twenty Nineteen" which is the correct format but the wrong date!! I tried the same test with another speaker (Sonos) and get the same announcement.
Something has definitely screwed up my %date% format/value and it also seems to have more than one value at the same time.
I have captured some logs this time and have also recorded the announcements on my phone to prove I'm not just cracking up! (update - can't upload the phone mp4)
This is still happening. Today it announced ninth of March instead of third of September.
Yesterday I also added a line into a rule that runs every day at 00.05 to set a GV to the %date% value of that rule. That has set it to 09/03/2019, so %date% is now definitely getting returned in US format for some strange reason.
It seems to be in the wrong format now everywhere I test it. It's as if as the %date% values for each rule get updated with a new trigger/event they are getting updated into US format. Dashboard dates are still showing correctly
Time for a reboot do you think?
EDIT. Update a new rule created now speaking %date% works correctly so it isn't wrong everywhere as I thought. But is very odd that anything using %date% early in the day seems to be the wrong format then after around 10am it seems OK!!!! Maybe %date% just isn't a morning person!
EDIT EDIT. Bizarrely it seems there might be something in that. I have just set another GV to %date% and that is in the correct format whereas the one created at 00.05 is in the wrong format. There were both set using the exact same command "set variable to %date%"