fix(isDate): Timezone Offset Fix

[tomaspanek]

This pull request resolves issues with false negatives when using the isDate validator (Issue #2256). When parsing dates, the YYYY-MM-DD date format gets interpreted to be in the UTC time zone (MDN Docs), while the getDate() method outputs the day of the month in the current time zone (MDN Docs). This apples-to-oranges comparison can result in occasional discrepancies, depending on the user's local time and timezone.

This PR appends T00:00:00 time information into the parsed string (as suggested by @brunoabude). That will cause the date string to be interpreted in the local time zone. Additionally, I added leading zeros for months and days (where applicable) to ensure that date strings always follow the ISO 8601 format (as intended in #2231).

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)
• References provided in PR (where applicable)

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (f074abd) 99.95% compared to head (873ed37) 99.95%.

Additional details and impacted files

@@ Coverage Diff @@## master #2257 +/- ##
=======================================
Coverage 99.95% 99.95% =======================================
Files 107 107 Lines 2436 2442 +6 Branches 615 617 +2 =======================================
+ Hits 2435 2441 +6 
Partials 1 1 

Files Changed	Coverage Δ
src/lib/isDate.js	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[WikiRik]

Please add some tests to ensure that we don't break this validator again

[tomaspanek]

I added in a test that mocks a different time zone. Passes when the isDate validator is implemented correctly.

Additionally, I found out that timestamps ending T00:00:00 are parsed differently before ES6/Node 8. Details here. To ensure maximum compatibility, dates are now getting parsed as full UTC strings (the getUTCDate() method then ensures the day of the month output is the same is input).

[brunoabude]

Nice catch on this ES2015 thing! It actually makes way more sense to use the full format with UTC+0 offset. I've also cherry-picked just the test with timezone-mock to the current master branch and confirmed that is failing with the current implementation.

Btw, there is a note on the timezone-mock package page that says:

Note: Future timezone transitions are likely to change due to laws, etc. Make sure to always test using specific dates in the past. The timezone data used by timezone-mock 1.0.4+ should be up accurate for all times through the end of 2018.

Would be nice to include dates up to 2018 to make the tests more resillient!

[tomaspanek]

Excellent point! I adjusted the unit test accordingly.

[WikiRik]

Not sure if the leading zeroes are actually needed, but using getUTCDate() instead of getDate() is fine with me.

The Node 6 test is failing, but it's not due to this PR

[WikiRik]

@profnandaa could you take a look at this and maybe get a patch release out since this bug got introduced by the latest version?

[profnandaa]

Anyone knows why this is failing on Node.js v6? We still need to support this, was helping us as proxy for some backward compatibility on browsers, thought I know in prod, there could be no one still using Node v6.

[profnandaa]

Would like to get this in once that is sorted. Will appreciate any help, thanks! @WikiRik@tomaspanek

[WikiRik]

Initially I thought it was not due to this PR since it didn't touch eslint dependency but other PRs are not failing so maybe the inclusion of timezone_mock did break it. Will take a look at it tonight

[tomaspanek]

@WikiRik@profnandaa Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6.

The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time.

[profnandaa]

Not seeing that failure on the last PR merged - https://github.com/validatorjs/validator.js/actions/runs/5069987300/job/1372 /na

…

On Thu, Aug 17, 2023, 17:05 Tomas Panek ***@***.***> wrote: @WikiRik <https://github.com/WikiRik> @profnandaa <https://github.com/profnandaa> Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6. The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time. — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEMGYQ7JZM37E54BXVDXVYQKRANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[WikiRik]

Indeed seems to be a flaky test since it passes now

[profnandaa]

I see. OK, let me merge and release in the next 24 hrs.

…

On Thu, Aug 17, 2023, 22:14 Rik Smale ***@***.***> wrote: Indeed seems to be a flaky test since it passes now — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEKU5GQCGIOY2XYHWOLXVZUQHANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sacummings91]

Does anyone know what's going on with this? Seems like it was supposed to be released months ago. We haven't been able to update validator to the latest because of this issue

[manojmula]

@sacummings91 can you please explain me what is the failing scenario for you so I can help you out with.

[sacummings91]

To be completely honest it's been so long now I can't remember the details exactly. I believe this comparison was off by 1 but I can't remember how I was able to surface it

new Date(`${fullYear}-${dateObj.m}-${dateObj.d}`).getDate() === +dateObj.d;

[tomaspanek]

@sacummings91 the issue was caused by the getDate() method returning the day in UTC, which could differ from the actual date being parsed if the runtime environment has a timezone to the west of UTC+0.

This PR has been merged, but it has not been released as part of a new version yet, see #2269. The package maintainers faced some challenges preparing a new build way back in August – given the delay, I assume things just have been very busy on their end.

Unless you need any new features/fixes introduced in the 13.11.0 version, I'd recommend using the 13.9.0 version. In case you have the validator package as a dependency of a dependency, you can include the following in your package.json:

If using yarn:

{
"resolutions": {
"validator": "13.9.0"
}
}

If using npm:

{
"overrides": {
"validator": "13.9.0"
}
}

Hopefully the new release will be out sometime soon!

[sacummings91]

Hey @tomaspanek, thanks for the update. I was mainly curious why it never got updated because I remember I saw it was about to be updated when I was originally dealing with this issue back in August. We have in fact pinned our version to 13.9.0 and aren't facing any issues with that version. I was just checking in to see when it might be safe to update to a newer version and noticed it still hasn't been updated.

[tomaspanek]

This pull request resolves issues with false negatives when using the isDate validator (Issue #2256). When parsing dates, the YYYY-MM-DD date format gets interpreted to be in the UTC time zone (MDN Docs), while the getDate() method outputs the day of the month in the current time zone (MDN Docs). This apples-to-oranges comparison can result in occasional discrepancies, depending on the user's local time and timezone.

This PR appends T00:00:00 time information into the parsed string (as suggested by @brunoabude). That will cause the date string to be interpreted in the local time zone. Additionally, I added leading zeros for months and days (where applicable) to ensure that date strings always follow the ISO 8601 format (as intended in #2231).

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)
• References provided in PR (where applicable)

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (f074abd) 99.95% compared to head (873ed37) 99.95%.

Additional details and impacted files

@@ Coverage Diff @@## master #2257 +/- ##
=======================================
Coverage 99.95% 99.95% =======================================
Files 107 107 Lines 2436 2442 +6 Branches 615 617 +2 =======================================
+ Hits 2435 2441 +6 
Partials 1 1 

Files Changed	Coverage Δ
src/lib/isDate.js	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[WikiRik]

Please add some tests to ensure that we don't break this validator again

[tomaspanek]

I added in a test that mocks a different time zone. Passes when the isDate validator is implemented correctly.

Additionally, I found out that timestamps ending T00:00:00 are parsed differently before ES6/Node 8. Details here. To ensure maximum compatibility, dates are now getting parsed as full UTC strings (the getUTCDate() method then ensures the day of the month output is the same is input).

[brunoabude]

Nice catch on this ES2015 thing! It actually makes way more sense to use the full format with UTC+0 offset. I've also cherry-picked just the test with timezone-mock to the current master branch and confirmed that is failing with the current implementation.

Btw, there is a note on the timezone-mock package page that says:

Note: Future timezone transitions are likely to change due to laws, etc. Make sure to always test using specific dates in the past. The timezone data used by timezone-mock 1.0.4+ should be up accurate for all times through the end of 2018.

Would be nice to include dates up to 2018 to make the tests more resillient!

[tomaspanek]

Excellent point! I adjusted the unit test accordingly.

[WikiRik]

Not sure if the leading zeroes are actually needed, but using getUTCDate() instead of getDate() is fine with me.

The Node 6 test is failing, but it's not due to this PR

[WikiRik]

@profnandaa could you take a look at this and maybe get a patch release out since this bug got introduced by the latest version?

[profnandaa]

Anyone knows why this is failing on Node.js v6? We still need to support this, was helping us as proxy for some backward compatibility on browsers, thought I know in prod, there could be no one still using Node v6.

[profnandaa]

Would like to get this in once that is sorted. Will appreciate any help, thanks! @WikiRik@tomaspanek

[WikiRik]

Initially I thought it was not due to this PR since it didn't touch eslint dependency but other PRs are not failing so maybe the inclusion of timezone_mock did break it. Will take a look at it tonight

[tomaspanek]

@WikiRik@profnandaa Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6.

The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time.

[profnandaa]

Not seeing that failure on the last PR merged - https://github.com/validatorjs/validator.js/actions/runs/5069987300/job/1372 /na

…

On Thu, Aug 17, 2023, 17:05 Tomas Panek ***@***.***> wrote: @WikiRik <https://github.com/WikiRik> @profnandaa <https://github.com/profnandaa> Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6. The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time. — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEMGYQ7JZM37E54BXVDXVYQKRANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[WikiRik]

Indeed seems to be a flaky test since it passes now

[profnandaa]

I see. OK, let me merge and release in the next 24 hrs.

…

On Thu, Aug 17, 2023, 22:14 Rik Smale ***@***.***> wrote: Indeed seems to be a flaky test since it passes now — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEKU5GQCGIOY2XYHWOLXVZUQHANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sacummings91]

Does anyone know what's going on with this? Seems like it was supposed to be released months ago. We haven't been able to update validator to the latest because of this issue

[manojmula]

@sacummings91 can you please explain me what is the failing scenario for you so I can help you out with.

[sacummings91]

To be completely honest it's been so long now I can't remember the details exactly. I believe this comparison was off by 1 but I can't remember how I was able to surface it

new Date(`${fullYear}-${dateObj.m}-${dateObj.d}`).getDate() === +dateObj.d;

[tomaspanek]

@sacummings91 the issue was caused by the getDate() method returning the day in UTC, which could differ from the actual date being parsed if the runtime environment has a timezone to the west of UTC+0.

This PR has been merged, but it has not been released as part of a new version yet, see #2269. The package maintainers faced some challenges preparing a new build way back in August – given the delay, I assume things just have been very busy on their end.

Unless you need any new features/fixes introduced in the 13.11.0 version, I'd recommend using the 13.9.0 version. In case you have the validator package as a dependency of a dependency, you can include the following in your package.json:

If using yarn:

{
"resolutions": {
"validator": "13.9.0"
}
}

If using npm:

{
"overrides": {
"validator": "13.9.0"
}
}

Hopefully the new release will be out sometime soon!

[sacummings91]

Hey @tomaspanek, thanks for the update. I was mainly curious why it never got updated because I remember I saw it was about to be updated when I was originally dealing with this issue back in August. We have in fact pinned our version to 13.9.0 and aren't facing any issues with that version. I was just checking in to see when it might be safe to update to a newer version and noticed it still hasn't been updated.

[tomaspanek]

This pull request resolves issues with false negatives when using the isDate validator (Issue #2256). When parsing dates, the YYYY-MM-DD date format gets interpreted to be in the UTC time zone (MDN Docs), while the getDate() method outputs the day of the month in the current time zone (MDN Docs). This apples-to-oranges comparison can result in occasional discrepancies, depending on the user's local time and timezone.

This PR appends T00:00:00 time information into the parsed string (as suggested by @brunoabude). That will cause the date string to be interpreted in the local time zone. Additionally, I added leading zeros for months and days (where applicable) to ensure that date strings always follow the ISO 8601 format (as intended in #2231).

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)
• References provided in PR (where applicable)

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (f074abd) 99.95% compared to head (873ed37) 99.95%.

Additional details and impacted files

@@ Coverage Diff @@## master #2257 +/- ##
=======================================
Coverage 99.95% 99.95% =======================================
Files 107 107 Lines 2436 2442 +6 Branches 615 617 +2 =======================================
+ Hits 2435 2441 +6 
Partials 1 1 

Files Changed	Coverage Δ
src/lib/isDate.js	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[WikiRik]

Please add some tests to ensure that we don't break this validator again

[tomaspanek]

I added in a test that mocks a different time zone. Passes when the isDate validator is implemented correctly.

Additionally, I found out that timestamps ending T00:00:00 are parsed differently before ES6/Node 8. Details here. To ensure maximum compatibility, dates are now getting parsed as full UTC strings (the getUTCDate() method then ensures the day of the month output is the same is input).

[brunoabude]

Nice catch on this ES2015 thing! It actually makes way more sense to use the full format with UTC+0 offset. I've also cherry-picked just the test with timezone-mock to the current master branch and confirmed that is failing with the current implementation.

Btw, there is a note on the timezone-mock package page that says:

Note: Future timezone transitions are likely to change due to laws, etc. Make sure to always test using specific dates in the past. The timezone data used by timezone-mock 1.0.4+ should be up accurate for all times through the end of 2018.

Would be nice to include dates up to 2018 to make the tests more resillient!

[tomaspanek]

Excellent point! I adjusted the unit test accordingly.

[WikiRik]

Not sure if the leading zeroes are actually needed, but using getUTCDate() instead of getDate() is fine with me.

The Node 6 test is failing, but it's not due to this PR

[WikiRik]

@profnandaa could you take a look at this and maybe get a patch release out since this bug got introduced by the latest version?

[profnandaa]

Anyone knows why this is failing on Node.js v6? We still need to support this, was helping us as proxy for some backward compatibility on browsers, thought I know in prod, there could be no one still using Node v6.

[profnandaa]

Would like to get this in once that is sorted. Will appreciate any help, thanks! @WikiRik@tomaspanek

[WikiRik]

Initially I thought it was not due to this PR since it didn't touch eslint dependency but other PRs are not failing so maybe the inclusion of timezone_mock did break it. Will take a look at it tonight

[tomaspanek]

@WikiRik@profnandaa Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6.

The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time.

[profnandaa]

Not seeing that failure on the last PR merged - https://github.com/validatorjs/validator.js/actions/runs/5069987300/job/1372 /na

…

On Thu, Aug 17, 2023, 17:05 Tomas Panek ***@***.***> wrote: @WikiRik <https://github.com/WikiRik> @profnandaa <https://github.com/profnandaa> Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6. The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time. — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEMGYQ7JZM37E54BXVDXVYQKRANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[WikiRik]

Indeed seems to be a flaky test since it passes now

[profnandaa]

I see. OK, let me merge and release in the next 24 hrs.

…

On Thu, Aug 17, 2023, 22:14 Rik Smale ***@***.***> wrote: Indeed seems to be a flaky test since it passes now — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEKU5GQCGIOY2XYHWOLXVZUQHANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sacummings91]

Does anyone know what's going on with this? Seems like it was supposed to be released months ago. We haven't been able to update validator to the latest because of this issue

[manojmula]

@sacummings91 can you please explain me what is the failing scenario for you so I can help you out with.

[sacummings91]

To be completely honest it's been so long now I can't remember the details exactly. I believe this comparison was off by 1 but I can't remember how I was able to surface it

new Date(`${fullYear}-${dateObj.m}-${dateObj.d}`).getDate() === +dateObj.d;

[tomaspanek]

@sacummings91 the issue was caused by the getDate() method returning the day in UTC, which could differ from the actual date being parsed if the runtime environment has a timezone to the west of UTC+0.

This PR has been merged, but it has not been released as part of a new version yet, see #2269. The package maintainers faced some challenges preparing a new build way back in August – given the delay, I assume things just have been very busy on their end.

Unless you need any new features/fixes introduced in the 13.11.0 version, I'd recommend using the 13.9.0 version. In case you have the validator package as a dependency of a dependency, you can include the following in your package.json:

If using yarn:

{
"resolutions": {
"validator": "13.9.0"
}
}

If using npm:

{
"overrides": {
"validator": "13.9.0"
}
}

Hopefully the new release will be out sometime soon!

[sacummings91]

Hey @tomaspanek, thanks for the update. I was mainly curious why it never got updated because I remember I saw it was about to be updated when I was originally dealing with this issue back in August. We have in fact pinned our version to 13.9.0 and aren't facing any issues with that version. I was just checking in to see when it might be safe to update to a newer version and noticed it still hasn't been updated.

[tomaspanek]

This pull request resolves issues with false negatives when using the isDate validator (Issue #2256). When parsing dates, the YYYY-MM-DD date format gets interpreted to be in the UTC time zone (MDN Docs), while the getDate() method outputs the day of the month in the current time zone (MDN Docs). This apples-to-oranges comparison can result in occasional discrepancies, depending on the user's local time and timezone.

This PR appends T00:00:00 time information into the parsed string (as suggested by @brunoabude). That will cause the date string to be interpreted in the local time zone. Additionally, I added leading zeros for months and days (where applicable) to ensure that date strings always follow the ISO 8601 format (as intended in #2231).

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)
• References provided in PR (where applicable)

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (f074abd) 99.95% compared to head (873ed37) 99.95%.

Additional details and impacted files

@@ Coverage Diff @@## master #2257 +/- ##
=======================================
Coverage 99.95% 99.95% =======================================
Files 107 107 Lines 2436 2442 +6 Branches 615 617 +2 =======================================
+ Hits 2435 2441 +6 
Partials 1 1 

Files Changed	Coverage Δ
src/lib/isDate.js	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[WikiRik]

Please add some tests to ensure that we don't break this validator again

[tomaspanek]

I added in a test that mocks a different time zone. Passes when the isDate validator is implemented correctly.

Additionally, I found out that timestamps ending T00:00:00 are parsed differently before ES6/Node 8. Details here. To ensure maximum compatibility, dates are now getting parsed as full UTC strings (the getUTCDate() method then ensures the day of the month output is the same is input).

[brunoabude]

Nice catch on this ES2015 thing! It actually makes way more sense to use the full format with UTC+0 offset. I've also cherry-picked just the test with timezone-mock to the current master branch and confirmed that is failing with the current implementation.

Btw, there is a note on the timezone-mock package page that says:

Note: Future timezone transitions are likely to change due to laws, etc. Make sure to always test using specific dates in the past. The timezone data used by timezone-mock 1.0.4+ should be up accurate for all times through the end of 2018.

Would be nice to include dates up to 2018 to make the tests more resillient!

[tomaspanek]

Excellent point! I adjusted the unit test accordingly.

[WikiRik]

Not sure if the leading zeroes are actually needed, but using getUTCDate() instead of getDate() is fine with me.

The Node 6 test is failing, but it's not due to this PR

[WikiRik]

@profnandaa could you take a look at this and maybe get a patch release out since this bug got introduced by the latest version?

[profnandaa]

Anyone knows why this is failing on Node.js v6? We still need to support this, was helping us as proxy for some backward compatibility on browsers, thought I know in prod, there could be no one still using Node v6.

[profnandaa]

Would like to get this in once that is sorted. Will appreciate any help, thanks! @WikiRik@tomaspanek

[WikiRik]

Initially I thought it was not due to this PR since it didn't touch eslint dependency but other PRs are not failing so maybe the inclusion of timezone_mock did break it. Will take a look at it tonight

[tomaspanek]

@WikiRik@profnandaa Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6.

The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time.

[profnandaa]

Not seeing that failure on the last PR merged - https://github.com/validatorjs/validator.js/actions/runs/5069987300/job/1372 /na

…

On Thu, Aug 17, 2023, 17:05 Tomas Panek ***@***.***> wrote: @WikiRik <https://github.com/WikiRik> @profnandaa <https://github.com/profnandaa> Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6. The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time. — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEMGYQ7JZM37E54BXVDXVYQKRANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[WikiRik]

Indeed seems to be a flaky test since it passes now

[profnandaa]

I see. OK, let me merge and release in the next 24 hrs.

…

On Thu, Aug 17, 2023, 22:14 Rik Smale ***@***.***> wrote: Indeed seems to be a flaky test since it passes now — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEKU5GQCGIOY2XYHWOLXVZUQHANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sacummings91]

Does anyone know what's going on with this? Seems like it was supposed to be released months ago. We haven't been able to update validator to the latest because of this issue

[manojmula]

@sacummings91 can you please explain me what is the failing scenario for you so I can help you out with.

[sacummings91]

To be completely honest it's been so long now I can't remember the details exactly. I believe this comparison was off by 1 but I can't remember how I was able to surface it

new Date(`${fullYear}-${dateObj.m}-${dateObj.d}`).getDate() === +dateObj.d;

[tomaspanek]

@sacummings91 the issue was caused by the getDate() method returning the day in UTC, which could differ from the actual date being parsed if the runtime environment has a timezone to the west of UTC+0.

This PR has been merged, but it has not been released as part of a new version yet, see #2269. The package maintainers faced some challenges preparing a new build way back in August – given the delay, I assume things just have been very busy on their end.

Unless you need any new features/fixes introduced in the 13.11.0 version, I'd recommend using the 13.9.0 version. In case you have the validator package as a dependency of a dependency, you can include the following in your package.json:

If using yarn:

{
"resolutions": {
"validator": "13.9.0"
}
}

If using npm:

{
"overrides": {
"validator": "13.9.0"
}
}

Hopefully the new release will be out sometime soon!

[sacummings91]

Hey @tomaspanek, thanks for the update. I was mainly curious why it never got updated because I remember I saw it was about to be updated when I was originally dealing with this issue back in August. We have in fact pinned our version to 13.9.0 and aren't facing any issues with that version. I was just checking in to see when it might be safe to update to a newer version and noticed it still hasn't been updated.

[tomaspanek]

This pull request resolves issues with false negatives when using the isDate validator (Issue #2256). When parsing dates, the YYYY-MM-DD date format gets interpreted to be in the UTC time zone (MDN Docs), while the getDate() method outputs the day of the month in the current time zone (MDN Docs). This apples-to-oranges comparison can result in occasional discrepancies, depending on the user's local time and timezone.

This PR appends T00:00:00 time information into the parsed string (as suggested by @brunoabude). That will cause the date string to be interpreted in the local time zone. Additionally, I added leading zeros for months and days (where applicable) to ensure that date strings always follow the ISO 8601 format (as intended in #2231).

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)
• References provided in PR (where applicable)

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (f074abd) 99.95% compared to head (873ed37) 99.95%.

Additional details and impacted files

@@ Coverage Diff @@## master #2257 +/- ##
=======================================
Coverage 99.95% 99.95% =======================================
Files 107 107 Lines 2436 2442 +6 Branches 615 617 +2 =======================================
+ Hits 2435 2441 +6 
Partials 1 1 

Files Changed	Coverage Δ
src/lib/isDate.js	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[WikiRik]

Please add some tests to ensure that we don't break this validator again

[tomaspanek]

I added in a test that mocks a different time zone. Passes when the isDate validator is implemented correctly.

Additionally, I found out that timestamps ending T00:00:00 are parsed differently before ES6/Node 8. Details here. To ensure maximum compatibility, dates are now getting parsed as full UTC strings (the getUTCDate() method then ensures the day of the month output is the same is input).

[brunoabude]

Nice catch on this ES2015 thing! It actually makes way more sense to use the full format with UTC+0 offset. I've also cherry-picked just the test with timezone-mock to the current master branch and confirmed that is failing with the current implementation.

Btw, there is a note on the timezone-mock package page that says:

Note: Future timezone transitions are likely to change due to laws, etc. Make sure to always test using specific dates in the past. The timezone data used by timezone-mock 1.0.4+ should be up accurate for all times through the end of 2018.

Would be nice to include dates up to 2018 to make the tests more resillient!

[tomaspanek]

Excellent point! I adjusted the unit test accordingly.

[WikiRik]

Not sure if the leading zeroes are actually needed, but using getUTCDate() instead of getDate() is fine with me.

The Node 6 test is failing, but it's not due to this PR

[WikiRik]

@profnandaa could you take a look at this and maybe get a patch release out since this bug got introduced by the latest version?

[profnandaa]

Anyone knows why this is failing on Node.js v6? We still need to support this, was helping us as proxy for some backward compatibility on browsers, thought I know in prod, there could be no one still using Node v6.

[profnandaa]

Would like to get this in once that is sorted. Will appreciate any help, thanks! @WikiRik@tomaspanek

[WikiRik]

Initially I thought it was not due to this PR since it didn't touch eslint dependency but other PRs are not failing so maybe the inclusion of timezone_mock did break it. Will take a look at it tonight

[tomaspanek]

@WikiRik@profnandaa Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6.

The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time.

[profnandaa]

Not seeing that failure on the last PR merged - https://github.com/validatorjs/validator.js/actions/runs/5069987300/job/1372 /na

…

On Thu, Aug 17, 2023, 17:05 Tomas Panek ***@***.***> wrote: @WikiRik <https://github.com/WikiRik> @profnandaa <https://github.com/profnandaa> Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6. The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time. — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEMGYQ7JZM37E54BXVDXVYQKRANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[WikiRik]

Indeed seems to be a flaky test since it passes now

[profnandaa]

I see. OK, let me merge and release in the next 24 hrs.

…

On Thu, Aug 17, 2023, 22:14 Rik Smale ***@***.***> wrote: Indeed seems to be a flaky test since it passes now — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEKU5GQCGIOY2XYHWOLXVZUQHANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sacummings91]

Does anyone know what's going on with this? Seems like it was supposed to be released months ago. We haven't been able to update validator to the latest because of this issue

[manojmula]

@sacummings91 can you please explain me what is the failing scenario for you so I can help you out with.

[sacummings91]

To be completely honest it's been so long now I can't remember the details exactly. I believe this comparison was off by 1 but I can't remember how I was able to surface it

new Date(`${fullYear}-${dateObj.m}-${dateObj.d}`).getDate() === +dateObj.d;

[tomaspanek]

@sacummings91 the issue was caused by the getDate() method returning the day in UTC, which could differ from the actual date being parsed if the runtime environment has a timezone to the west of UTC+0.

This PR has been merged, but it has not been released as part of a new version yet, see #2269. The package maintainers faced some challenges preparing a new build way back in August – given the delay, I assume things just have been very busy on their end.

Unless you need any new features/fixes introduced in the 13.11.0 version, I'd recommend using the 13.9.0 version. In case you have the validator package as a dependency of a dependency, you can include the following in your package.json:

If using yarn:

{
"resolutions": {
"validator": "13.9.0"
}
}

If using npm:

{
"overrides": {
"validator": "13.9.0"
}
}

Hopefully the new release will be out sometime soon!

[sacummings91]

Hey @tomaspanek, thanks for the update. I was mainly curious why it never got updated because I remember I saw it was about to be updated when I was originally dealing with this issue back in August. We have in fact pinned our version to 13.9.0 and aren't facing any issues with that version. I was just checking in to see when it might be safe to update to a newer version and noticed it still hasn't been updated.

[tomaspanek]

This pull request resolves issues with false negatives when using the isDate validator (Issue #2256). When parsing dates, the YYYY-MM-DD date format gets interpreted to be in the UTC time zone (MDN Docs), while the getDate() method outputs the day of the month in the current time zone (MDN Docs). This apples-to-oranges comparison can result in occasional discrepancies, depending on the user's local time and timezone.

This PR appends T00:00:00 time information into the parsed string (as suggested by @brunoabude). That will cause the date string to be interpreted in the local time zone. Additionally, I added leading zeros for months and days (where applicable) to ensure that date strings always follow the ISO 8601 format (as intended in #2231).

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)
• References provided in PR (where applicable)

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (f074abd) 99.95% compared to head (873ed37) 99.95%.

Additional details and impacted files

@@ Coverage Diff @@## master #2257 +/- ##
=======================================
Coverage 99.95% 99.95% =======================================
Files 107 107 Lines 2436 2442 +6 Branches 615 617 +2 =======================================
+ Hits 2435 2441 +6 
Partials 1 1 

Files Changed	Coverage Δ
src/lib/isDate.js	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[WikiRik]

Please add some tests to ensure that we don't break this validator again

[tomaspanek]

I added in a test that mocks a different time zone. Passes when the isDate validator is implemented correctly.

Additionally, I found out that timestamps ending T00:00:00 are parsed differently before ES6/Node 8. Details here. To ensure maximum compatibility, dates are now getting parsed as full UTC strings (the getUTCDate() method then ensures the day of the month output is the same is input).

[brunoabude]

Nice catch on this ES2015 thing! It actually makes way more sense to use the full format with UTC+0 offset. I've also cherry-picked just the test with timezone-mock to the current master branch and confirmed that is failing with the current implementation.

Btw, there is a note on the timezone-mock package page that says:

Note: Future timezone transitions are likely to change due to laws, etc. Make sure to always test using specific dates in the past. The timezone data used by timezone-mock 1.0.4+ should be up accurate for all times through the end of 2018.

Would be nice to include dates up to 2018 to make the tests more resillient!

[tomaspanek]

Excellent point! I adjusted the unit test accordingly.

[WikiRik]

Not sure if the leading zeroes are actually needed, but using getUTCDate() instead of getDate() is fine with me.

The Node 6 test is failing, but it's not due to this PR

[WikiRik]

@profnandaa could you take a look at this and maybe get a patch release out since this bug got introduced by the latest version?

[profnandaa]

Anyone knows why this is failing on Node.js v6? We still need to support this, was helping us as proxy for some backward compatibility on browsers, thought I know in prod, there could be no one still using Node v6.

[profnandaa]

Would like to get this in once that is sorted. Will appreciate any help, thanks! @WikiRik@tomaspanek

[WikiRik]

Initially I thought it was not due to this PR since it didn't touch eslint dependency but other PRs are not failing so maybe the inclusion of timezone_mock did break it. Will take a look at it tonight

[tomaspanek]

@WikiRik@profnandaa Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6.

The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time.

[profnandaa]

Not seeing that failure on the last PR merged - https://github.com/validatorjs/validator.js/actions/runs/5069987300/job/1372 /na

…

On Thu, Aug 17, 2023, 17:05 Tomas Panek ***@***.***> wrote: @WikiRik <https://github.com/WikiRik> @profnandaa <https://github.com/profnandaa> Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6. The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time. — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEMGYQ7JZM37E54BXVDXVYQKRANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[WikiRik]

Indeed seems to be a flaky test since it passes now

[profnandaa]

I see. OK, let me merge and release in the next 24 hrs.

…

On Thu, Aug 17, 2023, 22:14 Rik Smale ***@***.***> wrote: Indeed seems to be a flaky test since it passes now — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEKU5GQCGIOY2XYHWOLXVZUQHANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sacummings91]

Does anyone know what's going on with this? Seems like it was supposed to be released months ago. We haven't been able to update validator to the latest because of this issue

[manojmula]

@sacummings91 can you please explain me what is the failing scenario for you so I can help you out with.

[sacummings91]

To be completely honest it's been so long now I can't remember the details exactly. I believe this comparison was off by 1 but I can't remember how I was able to surface it

new Date(`${fullYear}-${dateObj.m}-${dateObj.d}`).getDate() === +dateObj.d;

[tomaspanek]

@sacummings91 the issue was caused by the getDate() method returning the day in UTC, which could differ from the actual date being parsed if the runtime environment has a timezone to the west of UTC+0.

This PR has been merged, but it has not been released as part of a new version yet, see #2269. The package maintainers faced some challenges preparing a new build way back in August – given the delay, I assume things just have been very busy on their end.

Unless you need any new features/fixes introduced in the 13.11.0 version, I'd recommend using the 13.9.0 version. In case you have the validator package as a dependency of a dependency, you can include the following in your package.json:

If using yarn:

{
"resolutions": {
"validator": "13.9.0"
}
}

If using npm:

{
"overrides": {
"validator": "13.9.0"
}
}

Hopefully the new release will be out sometime soon!

[sacummings91]

Hey @tomaspanek, thanks for the update. I was mainly curious why it never got updated because I remember I saw it was about to be updated when I was originally dealing with this issue back in August. We have in fact pinned our version to 13.9.0 and aren't facing any issues with that version. I was just checking in to see when it might be safe to update to a newer version and noticed it still hasn't been updated.

[tomaspanek]

This pull request resolves issues with false negatives when using the isDate validator (Issue #2256). When parsing dates, the YYYY-MM-DD date format gets interpreted to be in the UTC time zone (MDN Docs), while the getDate() method outputs the day of the month in the current time zone (MDN Docs). This apples-to-oranges comparison can result in occasional discrepancies, depending on the user's local time and timezone.

This PR appends T00:00:00 time information into the parsed string (as suggested by @brunoabude). That will cause the date string to be interpreted in the local time zone. Additionally, I added leading zeros for months and days (where applicable) to ensure that date strings always follow the ISO 8601 format (as intended in #2231).

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)
• References provided in PR (where applicable)

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (f074abd) 99.95% compared to head (873ed37) 99.95%.

Additional details and impacted files

@@ Coverage Diff @@## master #2257 +/- ##
=======================================
Coverage 99.95% 99.95% =======================================
Files 107 107 Lines 2436 2442 +6 Branches 615 617 +2 =======================================
+ Hits 2435 2441 +6 
Partials 1 1 

Files Changed	Coverage Δ
src/lib/isDate.js	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[WikiRik]

Please add some tests to ensure that we don't break this validator again

[tomaspanek]

I added in a test that mocks a different time zone. Passes when the isDate validator is implemented correctly.

Additionally, I found out that timestamps ending T00:00:00 are parsed differently before ES6/Node 8. Details here. To ensure maximum compatibility, dates are now getting parsed as full UTC strings (the getUTCDate() method then ensures the day of the month output is the same is input).

[brunoabude]

Nice catch on this ES2015 thing! It actually makes way more sense to use the full format with UTC+0 offset. I've also cherry-picked just the test with timezone-mock to the current master branch and confirmed that is failing with the current implementation.

Btw, there is a note on the timezone-mock package page that says:

Note: Future timezone transitions are likely to change due to laws, etc. Make sure to always test using specific dates in the past. The timezone data used by timezone-mock 1.0.4+ should be up accurate for all times through the end of 2018.

Would be nice to include dates up to 2018 to make the tests more resillient!

[tomaspanek]

Excellent point! I adjusted the unit test accordingly.

[WikiRik]

Not sure if the leading zeroes are actually needed, but using getUTCDate() instead of getDate() is fine with me.

The Node 6 test is failing, but it's not due to this PR

[WikiRik]

@profnandaa could you take a look at this and maybe get a patch release out since this bug got introduced by the latest version?

[profnandaa]

Anyone knows why this is failing on Node.js v6? We still need to support this, was helping us as proxy for some backward compatibility on browsers, thought I know in prod, there could be no one still using Node v6.

[profnandaa]

Would like to get this in once that is sorted. Will appreciate any help, thanks! @WikiRik@tomaspanek

[WikiRik]

Initially I thought it was not due to this PR since it didn't touch eslint dependency but other PRs are not failing so maybe the inclusion of timezone_mock did break it. Will take a look at it tonight

[tomaspanek]

@WikiRik@profnandaa Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6.

The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time.

[profnandaa]

Not seeing that failure on the last PR merged - https://github.com/validatorjs/validator.js/actions/runs/5069987300/job/1372 /na

…

On Thu, Aug 17, 2023, 17:05 Tomas Panek ***@***.***> wrote: @WikiRik <https://github.com/WikiRik> @profnandaa <https://github.com/profnandaa> Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6. The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time. — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEMGYQ7JZM37E54BXVDXVYQKRANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[WikiRik]

Indeed seems to be a flaky test since it passes now

[profnandaa]

I see. OK, let me merge and release in the next 24 hrs.

…

On Thu, Aug 17, 2023, 22:14 Rik Smale ***@***.***> wrote: Indeed seems to be a flaky test since it passes now — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEKU5GQCGIOY2XYHWOLXVZUQHANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sacummings91]

Does anyone know what's going on with this? Seems like it was supposed to be released months ago. We haven't been able to update validator to the latest because of this issue

[manojmula]

@sacummings91 can you please explain me what is the failing scenario for you so I can help you out with.

[sacummings91]

To be completely honest it's been so long now I can't remember the details exactly. I believe this comparison was off by 1 but I can't remember how I was able to surface it

new Date(`${fullYear}-${dateObj.m}-${dateObj.d}`).getDate() === +dateObj.d;

[tomaspanek]

@sacummings91 the issue was caused by the getDate() method returning the day in UTC, which could differ from the actual date being parsed if the runtime environment has a timezone to the west of UTC+0.

This PR has been merged, but it has not been released as part of a new version yet, see #2269. The package maintainers faced some challenges preparing a new build way back in August – given the delay, I assume things just have been very busy on their end.

Unless you need any new features/fixes introduced in the 13.11.0 version, I'd recommend using the 13.9.0 version. In case you have the validator package as a dependency of a dependency, you can include the following in your package.json:

If using yarn:

{
"resolutions": {
"validator": "13.9.0"
}
}

If using npm:

{
"overrides": {
"validator": "13.9.0"
}
}

Hopefully the new release will be out sometime soon!

[sacummings91]

Hey @tomaspanek, thanks for the update. I was mainly curious why it never got updated because I remember I saw it was about to be updated when I was originally dealing with this issue back in August. We have in fact pinned our version to 13.9.0 and aren't facing any issues with that version. I was just checking in to see when it might be safe to update to a newer version and noticed it still hasn't been updated.

[tomaspanek]

This pull request resolves issues with false negatives when using the isDate validator (Issue #2256). When parsing dates, the YYYY-MM-DD date format gets interpreted to be in the UTC time zone (MDN Docs), while the getDate() method outputs the day of the month in the current time zone (MDN Docs). This apples-to-oranges comparison can result in occasional discrepancies, depending on the user's local time and timezone.

This PR appends T00:00:00 time information into the parsed string (as suggested by @brunoabude). That will cause the date string to be interpreted in the local time zone. Additionally, I added leading zeros for months and days (where applicable) to ensure that date strings always follow the ISO 8601 format (as intended in #2231).

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)
• References provided in PR (where applicable)

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (f074abd) 99.95% compared to head (873ed37) 99.95%.

Additional details and impacted files

@@ Coverage Diff @@## master #2257 +/- ##
=======================================
Coverage 99.95% 99.95% =======================================
Files 107 107 Lines 2436 2442 +6 Branches 615 617 +2 =======================================
+ Hits 2435 2441 +6 
Partials 1 1 

Files Changed	Coverage Δ
src/lib/isDate.js	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[WikiRik]

Please add some tests to ensure that we don't break this validator again

[tomaspanek]

I added in a test that mocks a different time zone. Passes when the isDate validator is implemented correctly.

Additionally, I found out that timestamps ending T00:00:00 are parsed differently before ES6/Node 8. Details here. To ensure maximum compatibility, dates are now getting parsed as full UTC strings (the getUTCDate() method then ensures the day of the month output is the same is input).

[brunoabude]

Nice catch on this ES2015 thing! It actually makes way more sense to use the full format with UTC+0 offset. I've also cherry-picked just the test with timezone-mock to the current master branch and confirmed that is failing with the current implementation.

Btw, there is a note on the timezone-mock package page that says:

Note: Future timezone transitions are likely to change due to laws, etc. Make sure to always test using specific dates in the past. The timezone data used by timezone-mock 1.0.4+ should be up accurate for all times through the end of 2018.

Would be nice to include dates up to 2018 to make the tests more resillient!

[tomaspanek]

Excellent point! I adjusted the unit test accordingly.

[WikiRik]

Not sure if the leading zeroes are actually needed, but using getUTCDate() instead of getDate() is fine with me.

The Node 6 test is failing, but it's not due to this PR

[WikiRik]

@profnandaa could you take a look at this and maybe get a patch release out since this bug got introduced by the latest version?

[profnandaa]

Anyone knows why this is failing on Node.js v6? We still need to support this, was helping us as proxy for some backward compatibility on browsers, thought I know in prod, there could be no one still using Node v6.

[profnandaa]

Would like to get this in once that is sorted. Will appreciate any help, thanks! @WikiRik@tomaspanek

[WikiRik]

Initially I thought it was not due to this PR since it didn't touch eslint dependency but other PRs are not failing so maybe the inclusion of timezone_mock did break it. Will take a look at it tonight

[tomaspanek]

@WikiRik@profnandaa Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6.

The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time.

[profnandaa]

Not seeing that failure on the last PR merged - https://github.com/validatorjs/validator.js/actions/runs/5069987300/job/1372 /na

…

On Thu, Aug 17, 2023, 17:05 Tomas Panek ***@***.***> wrote: @WikiRik <https://github.com/WikiRik> @profnandaa <https://github.com/profnandaa> Any chance you could just re-run these checks, please? Since this package is distributed without lockfiles, it is possible that a minor version of a dependency (perhaps babel) had a glitch causing incomplete compilation for Node 6. The test was failing even before introducing the timezone-mock package; you also can find the same Node 6 issues within checks for other PRs from around the same time. — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEMGYQ7JZM37E54BXVDXVYQKRANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[WikiRik]

Indeed seems to be a flaky test since it passes now

[profnandaa]

I see. OK, let me merge and release in the next 24 hrs.

…

On Thu, Aug 17, 2023, 22:14 Rik Smale ***@***.***> wrote: Indeed seems to be a flaky test since it passes now — Reply to this email directly, view it on GitHub <#2257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7ZEKU5GQCGIOY2XYHWOLXVZUQHANCNFSM6AAAAAA3E6A7XY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sacummings91]

Does anyone know what's going on with this? Seems like it was supposed to be released months ago. We haven't been able to update validator to the latest because of this issue

[manojmula]

@sacummings91 can you please explain me what is the failing scenario for you so I can help you out with.

[sacummings91]

To be completely honest it's been so long now I can't remember the details exactly. I believe this comparison was off by 1 but I can't remember how I was able to surface it

new Date(`${fullYear}-${dateObj.m}-${dateObj.d}`).getDate() === +dateObj.d;

[tomaspanek]

@sacummings91 the issue was caused by the getDate() method returning the day in UTC, which could differ from the actual date being parsed if the runtime environment has a timezone to the west of UTC+0.

This PR has been merged, but it has not been released as part of a new version yet, see #2269. The package maintainers faced some challenges preparing a new build way back in August – given the delay, I assume things just have been very busy on their end.

Unless you need any new features/fixes introduced in the 13.11.0 version, I'd recommend using the 13.9.0 version. In case you have the validator package as a dependency of a dependency, you can include the following in your package.json:

If using yarn:

{
"resolutions": {
"validator": "13.9.0"
}
}

If using npm:

{
"overrides": {
"validator": "13.9.0"
}
}

Hopefully the new release will be out sometime soon!

[sacummings91]

Hey @tomaspanek, thanks for the update. I was mainly curious why it never got updated because I remember I saw it was about to be updated when I was originally dealing with this issue back in August. We have in fact pinned our version to 13.9.0 and aren't facing any issues with that version. I was just checking in to see when it might be safe to update to a newer version and noticed it still hasn't been updated.