exclude time from default date widget format #1143
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Deploy preview for netlify-cms-www ready! Built with commit cc30539 |
|
Deploy preview for cms-demo ready! Built with commit cc30539 |
tech4him1
suggested changes
Feb 28, 2018
| @@ -42,7 +42,7 @@ export default class DateControl extends React.Component { | |||
|
|
|||
| render() { | |||
| const { includeTime, value, classNameWrapper, setActiveStyle, setInactiveStyle } = this.props; | |||
| const format = this.format || moment.defaultFormat; | |||
| const format = this.format || moment[includeTime ? 'defaultFormat' : 'HTML5_FMT.DATE']; | |||
There was a problem hiding this comment.
'HTML5_FMT.DATE' won't work as it's not a key name, since DATE is a property of HTML5_FMT.
There was a problem hiding this comment.
const format = this.format || (includeTime ? moment.defaultFormat : moment.HTML5_FMT.DATE);should work (not tested)
|
I'm assuming this shouldn't be classified as a breaking change if we're just changing it to match our docs? It is changing the output of pre-existing entries, though. |
|
Right not, breaking, just a bugfix. This is the documented behavior and we weren't doing it. |
|
@tech4him1 fixed. |
tech4him1
suggested changes
Mar 2, 2018
|
Drat. |
|
@tech4him1 fixed 4 realz. |
tech4him1
approved these changes
Mar 2, 2018
tech4him1
suggested changes
Mar 2, 2018
tech4him1
changed the title
tech4him1
approved these changes
Mar 2, 2018
|
@erquhart I went ahead and pushed a commit to save the formatted value in Redux, feel free to revert if you don't like it. 😄 |
|
@tech4him1 much better place to do it, thank you. |
erquhart
added a commit
that referenced
this pull request
Apr 20, 2018
BREAKING CHANGE As of 1.0, the documented behavior for the date and datetime widgets was to always return a string value, but they were instead returning a date object if the default date was not manually changed by the user. This was addressed in #1143, but it became clear afterward that static site generators were depending on the raw date objects that Netlify CMS was unintentionally producing. Remaining as is or addressing the bug were both "breaking" states, so this commit reverts to producing raw date objects when no format is explicitly set. It is now considered an edge case to require string dates, as most static site generators expect to parse a raw date against formatting in a site's templates. Also note that this commit improves the original behavior by always providing a date object when no format is provided, even if the user manually changes the value.
erquhart
added a commit
that referenced
this pull request
Apr 20, 2018
BREAKING CHANGE As of 1.0, the documented behavior for the date and datetime widgets was to always return a string value, but they were instead returning a date object if the default date was not manually changed by the user. This was addressed in #1143, but it became clear afterward that static site generators were depending on the raw date objects that Netlify CMS was unintentionally producing. Remaining as is or addressing the bug were both "breaking" states, so this commit reverts to producing raw date objects when no format is explicitly set. It is now considered an edge case to require string dates, as most static site generators expect to parse a raw date against formatting in a site's templates. Also note that this commit improves the original behavior by always providing a date object when no format is provided, even if the user manually changes the value.
erquhart
added a commit
that referenced
this pull request
Apr 20, 2018
BREAKING CHANGE As of 1.0, the documented behavior for the date and datetime widgets was to always return a string value, but they were instead returning a date object if the default date was not manually changed by the user. This was addressed in #1143, but it became clear afterward that static site generators were depending on the raw date objects that Netlify CMS was unintentionally producing. Remaining as is or addressing the bug were both "breaking" states, so this commit reverts to producing raw date objects when no format is explicitly set. It is now considered an edge case to require string dates, as most static site generators expect to parse a raw date against formatting in a site's templates. Also note that this commit improves the original behavior by always providing a date object when no format is provided, even if the user manually changes the value.
erquhart
added a commit
that referenced
this pull request
Apr 20, 2018
BREAKING CHANGE As of 1.0, the documented behavior for the date and datetime widgets was to always return a string value, but they were instead returning a date object if the default date was not manually changed by the user. This was addressed in #1143, but it became clear afterward that static site generators were depending on the raw date objects that Netlify CMS was unintentionally producing. Remaining as is or addressing the bug were both "breaking" states, so this commit reverts to producing raw date objects when no format is explicitly set. It is now considered an edge case to require string dates, as most static site generators expect to parse a raw date against formatting in a site's templates. Also note that this commit improves the original behavior by always providing a date object when no format is provided, even if the user manually changes the value.
erquhart
added a commit
that referenced
this pull request
May 25, 2018
BREAKING CHANGE As of 1.0, the documented behavior for the date and datetime widgets was to always return a string value, but they were instead returning a date object if the default date was not manually changed by the user. This was addressed in #1143, but it became clear afterward that static site generators were depending on the raw date objects that Netlify CMS was unintentionally producing. Remaining as is or addressing the bug were both "breaking" states, so this commit reverts to producing raw date objects when no format is explicitly set. It is now considered an edge case to require string dates, as most static site generators expect to parse a raw date against formatting in a site's templates. Also note that this commit improves the original behavior by always providing a date object when no format is provided, even if the user manually changes the value.
erquhart
added a commit
that referenced
this pull request
May 25, 2018
* return date object from date/datetime widgets if no format set BREAKING CHANGE As of 1.0, the documented behavior for the date and datetime widgets was to always return a string value, but they were instead returning a date object if the default date was not manually changed by the user. This was addressed in #1143, but it became clear afterward that static site generators were depending on the raw date objects that Netlify CMS was unintentionally producing. Remaining as is or addressing the bug were both "breaking" states, so this commit reverts to producing raw date objects when no format is explicitly set. It is now considered an edge case to require string dates, as most static site generators expect to parse a raw date against formatting in a site's templates. Also note that this commit improves the original behavior by always providing a date object when no format is provided, even if the user manually changes the value. * produce raw date when no format is provided
brianlmacdonald
pushed a commit
to brianlmacdonald/netlify-cms
that referenced
this pull request
May 29, 2018
…org#1296) * return date object from date/datetime widgets if no format set BREAKING CHANGE As of 1.0, the documented behavior for the date and datetime widgets was to always return a string value, but they were instead returning a date object if the default date was not manually changed by the user. This was addressed in decaporg#1143, but it became clear afterward that static site generators were depending on the raw date objects that Netlify CMS was unintentionally producing. Remaining as is or addressing the bug were both "breaking" states, so this commit reverts to producing raw date objects when no format is explicitly set. It is now considered an edge case to require string dates, as most static site generators expect to parse a raw date against formatting in a site's templates. Also note that this commit improves the original behavior by always providing a date object when no format is provided, even if the user manually changes the value. * produce raw date when no format is provided
brianlmacdonald
pushed a commit
to brianlmacdonald/netlify-cms
that referenced
this pull request
May 29, 2018
…org#1296) * return date object from date/datetime widgets if no format set BREAKING CHANGE As of 1.0, the documented behavior for the date and datetime widgets was to always return a string value, but they were instead returning a date object if the default date was not manually changed by the user. This was addressed in decaporg#1143, but it became clear afterward that static site generators were depending on the raw date objects that Netlify CMS was unintentionally producing. Remaining as is or addressing the bug were both "breaking" states, so this commit reverts to producing raw date objects when no format is explicitly set. It is now considered an edge case to require string dates, as most static site generators expect to parse a raw date against formatting in a site's templates. Also note that this commit improves the original behavior by always providing a date object when no format is provided, even if the user manually changes the value. * produce raw date when no format is provided
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sets correct and documented format for Date widget (YYYY-MM-DD).
Closes #1119.