duckling suddenly can’t parse local timestamp

[erohmensing]

This happens when you don’t 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’s 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'

[erohmensing]

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

[msamogh]

@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"?

[erohmensing]

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?)

[msamogh]

when you don’t pass a timezone to the duckling configuration

I did pass a timezone and still got the same error.

[azharameen]

Hi, Is this issue fixed,

[erohmensing]

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.

[azharameen]

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.

[erohmensing]

@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.

[anushkmittal]

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

[fanlu]

replace "locale": self._locale()with"lang": self.language in duckling_http_extractor.py

[erohmensing]

@fanlu does this give the correctly-timezoned timestamp as well? If so, I'd love to take a contribution from you to fix it! 😃

[fanlu]

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}]

[nataliiao]

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.