After the last update, MyCroft is having issues ‘saying’ the correct day of the week. I notice this most often in the weather app. Examples (weather data is generally correct with ‘day’ being the only issue)…
Request: 'Hey MyCroft. Will it rain today'
Response: 'It will most likely not rain yesterday'
Request 'Hey MyCroft. Will it rain on Monday' (asked on Sunday, so Monday is 'tomorrow')
Response: 'It will not rain today'.
I thought it could simply be an issue with the starting day of the week, but other times, she will get the verbagge correct. and thus a different starting day of the week should not matter.
What platform are you on, and what time zone are you in? I’m especially interested in the time zone thing.
Mark I US Central Time Zone.
If I ask the ‘date’ or ‘time’, she gets them correct. Seems to be isolated more to referential days - yesterday, today and tomorrow.
I’m digging in the function, and it seems that ‘yesterday’ was an oversight, specific to English, most recently on my (non-professional FOSS guy) part. You can post an issue on GitHub, if you like, or I’ll take care of it (posting an issue) next time I get a break.
I can’t replicate the problem with “today” or with future relative DTs, but I have discovered a couple other quirks.
If you’re curious: the weather skill correctly recognizes that “yesterday” is a relative day (this comes from a vocabulary file) and then passes it along to a parser that turns words into a machine-usable datetime. Unfortunately, the parser doesn’t currently know what to do with “yesterday,” so it spits out its default output when it thinks it’s been passed garbage: today’s date.
As for “will it rain today” outputting “it will not rain yesterday,” that’s gonna bear separate investigation.
Having written this much, I should clarify that I don’t work for Mycroft, I just jumped in because I recently touched the datetime parsers (not that one, though.)
I went ahead and posted an issue at the Mycroft Core repository regarding “yesterday” as well as a few other things I found while I was digging. The problem with “today” parsing to “yesterday” is less obvious, and might be down to the weather skill, as I can’t replicate it by invoking the datetime parser directly. The Mycroft instance I’m working on thinks I’m in US/Central and it’s telling me today’s weather just fine
Thanks for the information (I like knowing things like this). I haven’t had a chance to look at it either, but thought it would be good to have the information in the wild so more eyes can check it out.
Thanks for reporting these, and for logging the extract_datetime issue too.
Going to get the weather timezone situation looked at this week, pretty sure it will be either retrieving the wrong report from OWM due to timezones, or that it’s evaluating the date of the report from an incorrect “now”. Eg if now is tomorrow then today is yesterday
what time of the day does this happen?
can you test before and after 12am? there is some logic around this to handle a special case that might be causing this weirdness
also please test using cli directly to rule out wrong STT transcriptions
i think the problem might be somewhere in the nice_date utils, doesn’t sound like it is in extract_datetime because “yesterday” wasn’t handled at all, i need to look into the weather skill and see if i can find the issue
I was thinking the ‘time of day’ requested could be part of it as well. This was around 8:00 pm which would be after midnight for UTC.
At the moment I can’t figure out how it’s even assembling “most likely”
Testing tonight to see if it has to do with the different days in UTC and US Central time and after 7:00 Central, she is now saying “I don’t have that information” for “Will it rain today”. Asking at 6:00 pm today and she answered correctly and asking at 7:00 pm she answers correctly for tomorrow (Wednesday).
NOTE - I also asked “will it rain on Tuesday” thinking I might get a different response, but she stuck with “I don’t have that information”.
One more update. Now that another hours has passed, she says ‘yesterday’ for today again. Guessing the time change (hasn’t changed in the US yet) is also causing issues.
Hey, we’ve tracked this one down, it definitely is the timezone issue. A fix should be coming shortly.
Fantastic. Thanks for the help and the great work.
Any update on when this fix might be coming out? I just updated to 20.2.0B and it is still an issue. While I know the information is correct, sad to have constantly hear the wrong day from a device designed to be helpful.
I had to re-image MyCrofts SD card and start her from scratch. After I had her setup, she did an update and then I manually updated the OS and rebooted her.
When she came up, I ask her where she was and the time and she answered correctly. I asked about tomorrow’s weather and she still incorrectly stated it as ‘today’.
I ran the ‘dpkg-reconfigure tzdata’ command after SSHing into her and select the US - Central timezone and rebooted her again.
When asked about tomorrow’s weather this time, she stated ‘tomorrow the weather…’.
In the past when I looked at her config to find her local, I did not run the above command. I am wondering if this was the issue then as well. Seems like there might be two different ways she is getting date/time information and both need to be set for her to truly ‘know’ the correct date.
that’s a current problem with the weather skill.Most of the methods use the internal method __extract_datetime(“today”) to determine the date (22,8,0,0.0) which has a to_utc method added in succession. Which means depending on your location it might fall back to 21,8,… I’ve planned to make a PR in the next couple of days.
To be precise: The code of the return value from __to_utc() is wrong. Instead of “when.replace(tzinfo=pytz.utc)” it should return “when.astimezone(pytz.utc)”. The fallback to “yesterday” happens elsewhere because of the replacement