Datepicker is off by one day if using the Y-m-d format #396
Comments
|
Hmm this is strange. I'm also able to reproduce this issue. I'm going to see if this is an issue on our end, or if it is an issue with |
asudoh
added a commit
to asudoh/carbon-components
that referenced
this issue
Nov 14, 2017
…ew Date() JavaScript Date constructor does not have proper i18n support when a string is given. You'll see a very ambiguous spec at: https://www.ecma-international.org/ecma-262/6.0/#sec-date.parse In the particular case of carbon-design-system#396, `new Date()` seems to think `Y-m-d` format as an ISO8601 UTC-based string, whereas `Y/m/d` seems to be treated as a locale-specific, local-timezone-based string. It ends up with producing a date object for the former case, that is of six hours before the clock for users in Austin, and thus one day off for the date part. Fixes carbon-design-system#396.
asudoh
added a commit
to asudoh/carbon-components
that referenced
this issue
Nov 14, 2017
…ew Date() JavaScript Date constructor does not have proper i18n support when a string is given. You'll see a very ambiguous spec at: https://www.ecma-international.org/ecma-262/6.0/#sec-date.parse In the particular case of carbon-design-system#396, `new Date()` seems to think `Y-m-d` format as an ISO8601 UTC-based string, whereas `Y/m/d` seems to be treated as a locale-specific, local-timezone-based string. It ends up with producing a date object for the former case, that is of six hours before the clock for users in Austin, and thus one day off for the date part. Fixes carbon-design-system#396.
marijohannessen
pushed a commit
that referenced
this issue
Nov 14, 2017
…ew Date() (#431) JavaScript Date constructor does not have proper i18n support when a string is given. You'll see a very ambiguous spec at: https://www.ecma-international.org/ecma-262/6.0/#sec-date.parse In the particular case of #396, `new Date()` seems to think `Y-m-d` format as an ISO8601 UTC-based string, whereas `Y/m/d` seems to be treated as a locale-specific, local-timezone-based string. It ends up with producing a date object for the former case, that is of six hours before the clock for users in Austin, and thus one day off for the date part. Fixes #396.
joshblack
added a commit
to joshblack/carbon
that referenced
this issue
May 2, 2019
…em#396) By default, `<button>` in a form will submit the form if it's interacted with. Adding `type="button"` here will cause this not to be the default behavior.
joshblack
added a commit
to joshblack/carbon
that referenced
this issue
May 8, 2019
…stem#396) * chore: check-in work * refactor(grid): update scss folder structure and mixins * chore(grid): update preview to be easier to work with * chore(grid): update preview example The hang example was not showing a realistic scenario for when one might use it. This commit includes a full-width image example to showcase how this could be used alongside a functional example. * chore(grid): update example to make condensed easier to read * chore(grid): update example to clarify
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Detailed description
If I set the data-date-format on the datepicker component to "Y-m-d" then the date selected is always one day off. For example, picking October 21, 2017 from the calendar popup will always set the text in the input to 2017-10-20. HTML here:
<input type="text" id="date-picker-3" class="bx--date-picker__input" placeholder="yyyy-mm-dd" data-date-picker-input data-date-format="Y-m-d"/>Reproduced on Chrome and Firefox.
The text was updated successfully, but these errors were encountered: