-
Notifications
You must be signed in to change notification settings - Fork 7k
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
Parsing failures with day of week tokens (ddd or dddd) #4227
Parsing failures with day of week tokens (ddd or dddd) #4227
Comments
I ran into this issue via I believe it's related to a specific hourly time issue. Potentially tied to inputting the day of week.
And
Further details:
|
I can confirm that this is indeed happening in 2.19.1. When Short term workaround, in the case of This workaround isn't helpful, of course, if your input is just |
I am not sure when omitting For example, |
Just an observation from my side here, when I encountered this issue in my project. Maybe it is helpful. I'm on a Ubuntu 14.04 VM (through Vagrant) and when I set my local timezone to be > moment.tz('maandag 16 oktober 2017, 21:22', 'dddd D MMMM YYYY, HH:mm', 'nl', true, 'Europe/Amsterdam').isValid();
true
> moment.tz('maandag 16 oktober 2017, 22:22', 'dddd D MMMM YYYY, HH:mm', 'nl', true, 'Europe/Amsterdam').isValid();
true
> moment.tz('dinsdag 16 oktober 2017, 22:22', 'dddd D MMMM YYYY, HH:mm', 'nl', true, 'Europe/Amsterdam').isValid();
false // expected, as 16 October was not on a Tuesday However, when I change my local timezone to > moment.tz('maandag 16 oktober 2017, 21:22', 'dddd D MMMM YYYY, HH:mm', 'nl', true, 'Europe/Amsterdam').isValid();
true
> moment.tz('maandag 16 oktober 2017, 22:22', 'dddd D MMMM YYYY, HH:mm', 'nl', true, 'Europe/Amsterdam').isValid();
false // this is wrong!
> moment.tz('dinsdag 16 oktober 2017, 21:22', 'dddd D MMMM YYYY, HH:mm', 'nl', true, 'Europe/Amsterdam').isValid();
true // expected, as 16 October was not on a Tuesday
> moment.tz('dinsdag 16 oktober 2017, 22:22', 'dddd D MMMM YYYY, HH:mm', 'nl', true, 'Europe/Amsterdam').isValid();
true // this is wrong! Could this be related to daylight saving time (CEST)? It changed on October 29th, when I change the date in my examples above to Monday October 30th, I get slightly different (but not error-free) results: > moment.tz('maandag 30 oktober 2017, 21:22', 'dddd D MMMM YYYY, HH:mm', 'nl', true, 'Europe/Amsterdam').isValid();
true
> moment.tz('maandag 30 oktober 2017, 22:22', 'dddd D MMMM YYYY, HH:mm', 'nl', true, 'Europe/Amsterdam').isValid();
true
> moment.tz('maandag 16 oktober 2017, 23:22', 'dddd D MMMM YYYY, HH:mm', 'nl', true, 'Europe/Amsterdam').isValid();
false // this is wrong! |
This needs fixing. |
Hey ! https://jsfiddle.net/bryxzq14/ (today is 03/11/2023 and nextWeekDate.format() used is '2023-11-10T00:49:51+01:00') |
Description of the Issue and Steps to Reproduce:
The above snippet works well with 2.18.1 but not with 2.19.0. It gives an InvalidDate.
Please include the values of all variables used.
Environment: Windows 10/ OSX node.js version 7.10 and 8.5.0
Examples: Chrome 49 on OSX, Internet Explorer 10 on Windows 7, Node.JS 4.4.4 on Ubuntu 16.0.4
Both the browser and the OS are important to us, particularly if you have an unsual environment like an IOT application.
Other information that may be helpful:
If you are reporting an issue, please run the following code in the environment you are using and include the output:
Ensure your issue is isolated to moment. Issues involving third party tools will be closed unless submitted by the tool's author/maintainer.
The text was updated successfully, but these errors were encountered: