wanasit / chrono

A natural language date parser in Javascript
MIT License
4.55k stars 340 forks source link

`parseResult.text` Missing Prefix "in" for Relative Time Expressions #528

Closed ilDon closed 1 year ago

ilDon commented 1 year ago

Description:

If a relative time expression has the prefix "in", the parseResult.text omits this prefix. This inconsistency makes it difficult to match the result against the library a second time since the text without the "in " is no longer parsed as a date

Steps to Reproduce:

  1. Parse a relative time expression with the "in" prefix:
let result = chrono.parse('in 1 month');
  1. Observe the parseResult.text value:
console.log(result[0].text);  // Outputs: "1 month"

Expected Behavior:

The parseResult.text value should be "in 1 month".

Actual Behavior:

The parseResult.text value is "1 month", missing the "in" prefix.

Impact:

This behavior makes it challenging to check the parsed result against the library again since the "in" prefix is missing. It would be helpful to have a consistent representation of the parsed text in parseResult.text.

Environment:

chrono-node version: 2.6.4

wanasit commented 1 year ago

Hello @ilDon.

Thanks for reporting this, but I cannot reproduce the issue that you mention on the latest codebase (see. 2d09189).

Could you share more details about your project? Ideally, could you send me a link to a code example I could checkout and try?

ilDon commented 1 year ago

I'm not able to reproduce this anymore with 2.6.6 either :-)

ilDon commented 1 year ago

I stand corrected, I am able to reproduce this bug also in 2.6.6.

Try this:

const configuration = chrono.casual.defaultConfig.createCasualConfiguration(false)
const chronoInstance = new chrono.Chrono(configuration)
const forwardFrom = new Date()
const result = chronoInstance.parse(text, forwardFrom, { startDayHour: 8 })

.text will be 1 month, without in

wanasit commented 1 year ago

ok. I found a bug with {forwardDate: true} options (not { startDayHour: 8 } in your example though).

Could you check if it's fixed in: 2421760810fba9769dd3232405ae6c5c6f893693 (should be in 2.7.0+).