React-dates: Discussion on Date format.

[nsisodiya]

I checked out documentation and It looks like Datepicker take moment object.
I do not understand why Date picker of this world cannot adopt the world most simple and unconfusing format.
YYYY-MM-DD.
As per my experience, IMHO, A date picker must communicate in YYYY-MM-DD format which is most simple and minimum sufficient.

[majapw]

Hello! If you are talking about the display format, currently the date picker defaults to moment's L format which changes from locale to locale. However, https://github.com/airbnb/react-dates/pull/52 should allow you to specify YYYY-MM-DD and other formats as you like! Will that help?

Currently, regardless of whatever format is displayed, you should be able to type in YYYY-MM-DD format.

[majapw]

I _think_ this is ultimately a duplicate of https://github.com/airbnb/react-dates/issues/26, but I'll wait for confirmation from @nsisodiya before closing this issue. :)

[nsisodiya]

@majapw No i am not talking about Display format. Display format is a different topic.
I am concern about Input/Output exchange format.
Display format should be User choice.
IMHO - Date or more precisely Day (appx 24 hour duration) has nothing to do with timezone or time component. YYYY-MM-DD format is sufficient for Input, output.
Let me give example -
The most simple Date Picker is 3 dropdowns, (Year, Month, Day). No Here there is no time or timezone notion associated here. YYYY-MM-DD is sufficient to go inside and come outside in these 3 dropdowns.
Your date picker is another UI representation of simple 3 dropdown based date picker.

[majapw]

So we're using moment objects as our output which should be very easily converted to ISO formats. Can you describe the exact issue you're dealing with and why it is causing you some difficulty (slash is something that we can fix in the internals)?

[nsisodiya]

@majapw - I know we can convert to Moment object to ISO string format.
Same line, I want to say, just use ISO format, receiver will be having 2 options,

1. they can work on these strings directly
2. they can use Date or moment lib to do operation on these string.

Why be opinionated on output format and defining moment objects are standard way for communication.
If we send these output to server, it will be JSONfied string something like 2016-02-23T10:00:00.000Z. this is UTC timestamp of first millisecond of 2016-02-23. working with UTC string can create problem if sender generate these string with T1 as timezone and receiver try to understand them as T2 timezone.

My only point it - Output format be just YYYY-MM-DD format and let user decide how he wanna deal with the output.
Same true with input too.

[ljharb]

@nsisodiya in either case, you can go from one format to the other. The question is, is the more common case "you want a powerful/flexible moment object, that you can use to produce a multitude of formats including YYYY-MM-DD", or "you want a YYYY-MM-DD string"?

In either case you don't want to blindly JSON.stringify it and send it to the server, so in every case you may need to do your own formatting. It seems far more preferable to use a moment object to do that formatting, rather than to force every user of the library to either reinvent the wheel, or convert to moment themselves?

[majapw]

I think @ljharb put it eloquently and returning a moment object gives a lot of flexibility to the consumer. You can still convert it to ISO format at will so I think that the current implementation addresses your concerns.

[jeffsee55]

I think I may be caught between these two schools of thought and I'd love some assistance. There are cases in which I'd like to able to display a format (like L format) and have the actual input value represented as another (like YYYY-MM-DD). I don't have a layer between the form being submitted and sent to the server to do my own formatting and that seems to be where I need to address this concern but I did want to reach out to see if I'm missing something first. Thanks for everything, loving this component!

Current HTML output
````

Start Date

01-07-2017

````

Desired HTML output
````

Start Date

01-07-2017

````

[majapw]

Huh, so right now, we do require you to have a layer that interrupts the submit and formats the date accordingly if you want to submit something different. ... but also I'm a strong believer in that everything sent to the server should be in ISO format regardless of what is being displayed, so maybe it would make sense to default the actual input value attribute to be in YYYY-MM-DD format.

[jeffsee55]

Gotcha - that would suit my needs perfectly! But actually as I say that now there's really no reason to not have that layer. I'm using this component as a drop-in to an otherwise static form so I've got no other need for that layer. Perhaps that's a sign I need to expand the entire form to use react components... Anyway - yes this component as it stands sort of relies on that layer to be predictable if you want to use the L format which may or may not suit everyone (from my biased view).

[majapw]

Nah, I think you are right that the default value should be in a standardized format. Pretty much, 90% of my woes at Airbnb in the past have stemmed from using internationalized dates on the server-side/in urls/etc.

I've created https://github.com/airbnb/react-dates/pull/229 to address this issue.

[jeffsee55]

Excellent, thanks for this!