Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] DateRule assumes the date string to be in UTC #166

Open
psrajat opened this issue Feb 2, 2022 · 0 comments
Open

[bug] DateRule assumes the date string to be in UTC #166

psrajat opened this issue Feb 2, 2022 · 0 comments

Comments

@psrajat
Copy link

psrajat commented Feb 2, 2022

Description

While using the builtin DateRule validation rule, I noticed that it uses time.Parse.

time.Parse documentation states that:

In the absence of a time zone indicator, Parse returns a time in UTC.


If we provide date strings to DateRule validator without any timezone information, it will always assume it to be in UTC.
On top of it, DateRule doesn't provide any functionality to provide custom time.Location.

This is causing issues because the rule is failing when trying to compute whether the date is actually between minDate and maxDate for some cases where timezone is different and Min and Max are close to the input date string.

Here's an example demonstrating this behaviour: https://go.dev/play/p/JgKOS6i5oJZ

Proposal

This I feel is not the desired behaviour and I think DateRule should instead use time.ParseInLocation with a default timezone and also give users the option to provide a custom timezone if they want.

I am really not sure what should be the default timezone. I can think of 2 possibilities:

  1. Using time.Local as default but that would make it backward incompatible
  2. But if we go with time.UTC as default timezone it will make the validation logic more verbose as we'll have to specify timezone while defining each rule if our local timezone is different than UTC

Let me know what do you think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant