Make today/tomorrow/yesterday at the beginning of the day

[aviadl]

zero out hour/minutes/seconds when working with 'today/tomorrow/yesterday'

[dmitshur]

Issue #13 is related.

[tj]

👍 I think this makes sense as well, if you have something like "yesterday at 5pm", you'll still get the seconds of now, at least in my case (query range) that seems surprising.

Maybe an option to always zero anything that isn't specified?

[olebedev]

Well, it seems to be a case for plugging those rules you would like to use for a particular case. Example:

import (
	github.com/olebedev/when
	github.com/olebedev/when/rules/en
	github.com/olebedev/when/rules/common

	customENGRules github.com/demisto/when/rules/en // from the above
)
w := when.New(nil)
// this rule will match before the rest ones, the order is matters
w.Add(customENGRules.CasualDate)
// ... add whatever rules you want, like:
// w.Add(en.All...)
// w.Add(common.All...)

@tj, I think an option here is an unnecessarily in favor of using rules as building blocks for a case. Wdyt?

[olebedev]

@aviadl, I am happy to accept the rule you suggested but as an alternative rule which is not included in the default instance. Maybe a separate directory would be fine, like: rules/en/misc. And the README or Godoc with a description of the rule and examples, etc.

[aviadl]

@aviadl, I am happy to accept the rule you suggested but as an alternative rule which is not included in the default instance. Maybe a separate directory would be fine, like: rules/en/misc. And the README or Godoc with a description of the rule and examples, etc.

Not sure why the original one is valid, but i will let you take it from here, and do the changes you believe in

[tj]

Custom rules sounds reasonable to me, I didn't look at how they're implemented yet but I'll take a look!

[olebedev]

Not sure why the original one is valid, but i will let you take it from here, and do the changes you believe in

Hello @aviadl,

Thank you for your contribution. I appreciate the effort you put into this matter. After reconsideration, I agree with the change you suggested for "valid." However, I have one concern remaining. Users who are already utilizing the library may encounter unexpected behavior when they update it.

I'm considering whether it would be beneficial to introduce versioning to the library. I would like to hear your thoughts on this matter.

Related #16.

Best regards,
Oleg

[aviadl]

Not sure why the original one is valid, but i will let you take it from here, and do the changes you believe in

Hello @aviadl,

Thank you for your contribution. I appreciate the effort you put into this matter. After reconsideration, I agree with the change you suggested for "valid." However, I have one concern remaining. Users who are already utilizing the library may encounter unexpected behavior when they update it.

I'm considering whether it would be beneficial to introduce versioning to the library. I would like to hear your thoughts on this matter.

Related #16.

Best regards, Oleg

IMO i would treat the current behaviour as a bug, so i think that this fix is fine, and not need for versioning
we can also add a flag to the library whether to work this way or not, if you really are concerned about this

BTW - you can start working with git releases, and then it will change only for customers that take the latest release