Allow two digit year formatting

[brendonshih]

Currently the date picker only displays full four digit years (2021). I thought it might be a documentation oversight so I used the Unicode standard format year (yy) by trying M/d/yy and the date still comes out like 5/11/2021. It's pretty common for people to only want to display 2 digits due to space constraints so it would be nice if the formatter supported date formats like 5/11/21.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this issue will be closed in 14 days.

[voidname201]

Second this

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this issue will be closed in 14 days.

[brendonshih]

.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this issue will be closed in 14 days.

[wojtekmaj]

Unlikely to happen, because we have no way of knowing which century we should assume.

new Date().getYear() returns 122 at the moment of writing. So we wouldn't be able to use even that!

[brendonshih]

Two digit year display is a standard in many forms. It’s weird how you’re acting like it’s not possible to allow people to show 2022 as 22 simply because converting 22 to 2022 is slightly more difficult. This is about displaying 2022 as 22 not about converting a 2 digit year like 22 to 2022 in code. You don’t need to assume a year. This is about taking a known year and letting the user display less information (the last two digits). You already allow users to show less information by omitting the time from the date object.

On Wed, Sep 14, 2022 at 11:34 AM Wojciech Maj @.***> wrote:

Unlikely to happen, because we have no way of knowing which century we should assume.

new Date().getYear() returns 122 at the moment of writing. So we wouldn't be able to use even that!

— Reply to this email directly, view it on GitHub https://github.com/wojtekmaj/react-daterange-picker/issues/94#issuecomment-1247156461, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUXWITEBBM5B33J6EVIA63V6ILFDANCNFSM44XC3U4Q . You are receiving this because you modified the open/close state.Message ID: @.***>

[freerror]

When I looked at it did look there was quite a tight coupling between the representation and the actual value as stored in state. If you know a way @brendonshih (to separate the representation) you could submit a PR or provide an example (I would be happy to submit as a PR, but I don't have time to do it from scratch). Or worse case you could fork the project.

Just an observation that the tone of your message ("... it's weird how you're acting ...") came off quite rudely given that this is a free (and pretty awesome) project. I understand you've been waiting for some feedback for over year, but woktekmaj doesn't owe you a response.

[brendonshih]

You’re right. Apologies for being rude.

On Wed, Sep 14, 2022 at 5:42 PM appuser @.***> wrote:

When I looked at it did look there was quite a tight coupling between the representation and the actual value as stored in state. If you know a way @brendonshih https://github.com/brendonshih (to separate the representation) you could submit a PR or provide an example (I would be happy to submit as a PR, but I don't have time to do it from scratch). Or worse case you could fork the project.

Just an observation that the tone of your message ("... it's weird how you're acting ...") came off quite rudely given that this is a free (and pretty awesome) project. I understand you've been waiting for some feedback for over year, but woktekmaj doesn't owe you a response.

— Reply to this email directly, view it on GitHub https://github.com/wojtekmaj/react-daterange-picker/issues/94#issuecomment-1247440513, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUXWIRZXD6KGBLHQZZ6FZLV6JWHTANCNFSM44XC3U4Q . You are receiving this because you were mentioned.Message ID: @.***>

[freerror]

Unlikely to happen, because we have no way of knowing which century we should assume.

new Date().getYear() returns 122 at the moment of writing. So we wouldn't be able to use even that!

Could the option be passed in to react-date-picker/src/shared/dateFormatter.js as part of the options object? Maybe it could be set with some new prop(s) from "numeric" to "2-digit" in react-date/picker/src/DateInput.jsx in the getter:

get formatDate() {
    const { maxDetail } = this.props;

    const level = allViews.indexOf(maxDetail);
    const formatterOptions =
      getFormatterOptionsCache[level] ||
      (() => {
        const options = { year: 'numeric' };  // <- e.g. make this configurable somehow (to "2-digit")
        if (level >= 2) {
          options.month = 'numeric';
        }
        if (level >= 3) {
          options.day = 'numeric';
        }

        getFormatterOptionsCache[level] = options;

        return options;
      })();

    return getFormatter(formatterOptions);
  }

It's not in the MDM page for Intl.DateTimeFormat but I found that option mentioned here

If I have time after work I'll hard code it and see if it breaks things.

[wojtekmaj]

What worries me more is "un-formatting" it. Like, "70" should be 1970 or 2070? How do we decide? Should we require additional century (number) or parseYearToFullYear (function) prop in this case? Guess? 🤔

[freerror]

What worries me more is "un-formatting" it...

Hmm, if it's not currently the case, maybe the component could store the date in a "raw" format but a separate property in state could hold the value generated by the formatter. It's sounding like more work than I initially anticipated as I didn't think you'd need to switch between formats (e.g. to get the century) with only the formatted string of the date stored.

I'll update this comment if I spend more time looking at it, as I'm making a few assumptions. Just thinking out loud, I'm keen to check these assumptions:

• [ ] Date is stored once in its localized format and this is used throughout the component tree (rather than having a representation separate from the "real" value)