JarbasAI

To be clear my aim isn't targeting the bottom, just not forget that the bottom is there, the important thing is to make sure skill makers don't trip up on...

@krisgesling you have the final word, but i think this can be closed as it seems we reached a consensus We should however ensure extract_datetime and any future extract_XXX follow...

we could just add some util methods, extract_first_number and extract_last_number extract_first_number would only be syntactic sugar for convenience but would be an alias for extract_number, extract_last_number would be the recommended...

whoever picks up on this needs to write a test suite, i have identified tests that are returning the last number, most are returning the first a big TODO was...

actually extract_numbers wraps extract_number, ie, extract_number returns the left-most sequentially this seems to me like a missing break statement somewhere maybe, or maybe something implemented assuming we were under the...

i'm with ake on this one, deprecation warning should be there with that extra note and this issue should be pinned so it keeps support requests under control

[alarm skill handles this case](https://github.com/MycroftAI/skill-alarm/blob/20.08/__init__.py#L387 ) exactly as we propose ```python when, utt_no_datetime = extract_datetime(utt) or (None, utt) ``` but it should not break with proposed changes

> eg `$XDG_DATA_HOME/project-name/resources` this would be very useful, not only for devs but also allows users to do things like override the normalizer config

- extract_date - #96 - extract_time - TODO - extract_datetime refactor using extract_date + extract_time (language agnostic!) - TODO

would this make sense to be handled in the [normalizer](https://github.com/MycroftAI/lingua-franca/pull/55)?