This happens when ~you don鈥檛 pass a timezone to the~ duckling ~configuration and it~ tries to get your time using reference time.
I thought this was my new computer sending weird timestamps, but it鈥檚 happened on both old and new and was recently reported by a community member.
Warning:
2019-07-13 14:24:32 WARNING root - Could not parse timestamp fc976cc217934115b1f4b5d44b236d80. Instead current UTC time will be passed to duckling. Error: invalid literal for int() with base 10: 'fc976cc217934115b1f4b5d44b236d80'
This is a different warning, but may be related, when running rasa x, i got
2019-07-17 17:47:16 WARNING rasa.core.jobs - apscheduler could not find a timezone and is defaulting to utc. This is probably because your system timezone is not set. Set it with e.g. echo "Europe/Berlin" > /etc/timezone
Edit: that was on the binder though, not on my local machine -- no error when running rasa x on the machine that caused the duckling error
@erohmensing Just encountered the first error myself. By "need to change something in rasa/duckling", do you mean the Docker image rasa/duckling or "rasa or duckling"?
i meant rasa/duckling, but I get the error even when docker isn't running. I was wrong, the error gets thrown in rasa here (why the hell as root though?)
when you don鈥檛 pass a timezone to the duckling configuration
I did pass a timezone and still got the same error.
Hi, Is this issue fixed,
It isn't, the warning still shows. However, it doesn't seem to stop duckling from parsing dates at all, though it might be defaulting to UTC instead of time zone, i'm not sure.
Thanks @erohmensing.
In my app I want date of birth, the intent goes below threshold and default fallback action is executed. I thought this might be the reason. Thanks for the reply, i'll check my training data.
@azharameen you can use rasa shell nlu to see how your bot parses messages, to see if it's picking up the entities correctly. In general, rasa shell --debug is a good way to figure out why the fallback action is being executed.
bump same issue. I believe this is why it's giving me UTC -7 co-ordinates even though I am using "America/New_York" under time zone
replace "locale": self._locale()with"lang": self.language in duckling_http_extractor.py
@fanlu does this give the correctly-timezoned timestamp as well? If so, I'd love to take a contribution from you to fix it! 馃槂
Yes, I think there is no problem with timezone.
this is my test case below.
curl -XPOST http://0.0.0.0:8000/parse --data 'dims=time&lang=en&l&tz=Asia/Shanghai&text=tomorrow morning&reftime=1573475247000'
[{"body":"tomorrow morning","start":0,"value":{"values":[{"to":{"value":"2019-11-12T12:00:00.000+08:00","grain":"hour"},"from":{"value":"2019-11-12T00:00:00.000+08:00","grain":"hour"},"type":"interva
l"}],"to":{"value":"2019-11-12T12:00:00.000+08:00","grain":"hour"},"from":{"value":"2019-11-12T00:00:00.000+08:00","grain":"hour"},"type":"interval"},"end":16,"dim":"time","latent":false}]
curl -XPOST http://0.0.0.0:8000/parse --data 'dims=time&lang=en&l&tz=Europe/Berlin&text=tomorrow morning&reftime=1573475247000'
[{"body":"tomorrow morning","start":0,"value":{"values":[{"to":{"value":"2019-11-12T12:00:00.000+01:00","grain":"hour"},"from":{"value":"2019-11-12T00:00:00.000+01:00","grain":"hour"},"type":"interval"}],"to":{"value":"2019-11-12T12:00:00.000+01:00","grain":"hour"},"from":{"value":"2019-11-12T00:00:00.000+01:00","grain":"hour"},"type":"interval"},"end":16,"dim":"time","latent":false}]
This warning occurs because (as you can see) fc976cc217934115b1f4b5d44b236d80 is not a timestamp.
In rasa/core/processor.py:
parse_data = await self.interpreter.parse(message.text, message.message_id, tracker)
Where self.interpreter is an instance of the class RasaNLUInterpreter (in rasa/core/interpreter.py), and its parse method runs the following command:
self.interpreter.parse(text, message_id)
But self.interpreter in RasaNLUInterpreter is an instance of the Interpreter class (rasa/nlu/model.py) and its parse method takes text and time (not message_id) as arguments. So it receives message_id and tries to treat it like a timestamp, it can't and gives you a warning.
Most helpful comment
I did pass a timezone and still got the same error.