Skip to content
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

feat: Add fullDateWithWeekday, weekday and weekdayShort formatters #400

Merged
merged 11 commits into from
Jul 6, 2020

Conversation

philipbulley
Copy link
Contributor

@philipbulley philipbulley commented Jun 25, 2020

Addresses #399

I've used the following formatter strings:

Library fullDateWithWeekday weekday weekdayShort Formatter Docs
date-fns PPPP EEEE EEE date-fns
moment dddd, LL * dddd ddd Moment.js
luxon DDDD cccc ccc Luxon
dayjs dddd, LL dddd ddd Day.js
jalaali jYYYY, jMMMM Do, dddd * dddd ddd jalaali/moment-jalaali
hijri iYYYY, iMMMM Do, dddd * dddd ddd xsoh/moment-hijri
  • *Moment, jalaali and hijri don't have a preset localised formatter string suitable for fullDateWithWeekday, so I have improvised by adding dddd and documented fullDateWithWeekday as being "Partially localized". This may not be ideal across all locales — I see you've done something similar with keyboardDateTime12h, etc. I imagine this won't be a problem.
  • I don't understand the output of Hijiri and Jalaali utils, so can't verify. Same applies to the Russian in the formats.test. I've used a 'best guess' and have just copied the received values directly into the tests. Do you have anyone who can verify?
  • For clarity, I've aligned the examples in the docs with the test assertions (moment en-US) and figured I'd make a couple of grammar improvements on the README whilst I was there (hope you don't mind)
  • Prettier has reformatted a bunch of lines, not sure why this formatting wasn't in place already? I didn't change any prettier config.

Please let me know if you'd like to see any changes, or feel free to edit.

@codecov-commenter
Copy link

codecov-commenter commented Jun 25, 2020

Codecov Report

Merging #400 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff            @@
##            master      #400   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           14        14           
  Lines          692       692           
  Branches        76        76           
=========================================
  Hits           692       692           
Impacted Files Coverage Δ
...kages/date-fns-jalali/src/date-fns-jalali-utils.ts 100.00% <ø> (ø)
packages/date-fns/src/date-fns-utils.ts 100.00% <ø> (ø)
packages/dayjs/src/dayjs-utils.ts 100.00% <ø> (ø)
packages/hijri/src/hijri-utils.ts 100.00% <ø> (ø)
packages/jalaali/src/jalaali-utils.ts 100.00% <ø> (ø)
packages/luxon/src/luxon-utils.ts 100.00% <ø> (ø)
packages/moment/src/moment-utils.ts 100.00% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 442965f...a0d1a1a. Read the comment docs.

Copy link
Owner

@dmtrKovalenko dmtrKovalenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please run yarn prettier --write './packages/**/*.{js,jsx,ts,tsx,json,css,md,mdx}'.
And also what was the motivation of updating example comments?

Russian output is ok. For hijiri and jallali will wait for some native speaker open issue 🤷‍♂️

Or allow changing from maintainers in PR settings.

README.md Outdated Show resolved Hide resolved
__tests__/jalaali.test.ts Outdated Show resolved Hide resolved
packages/jalaali/src/jalaali-utils.ts Outdated Show resolved Hide resolved
@philipbulley
Copy link
Contributor Author

@c0m1t thanks for taking a look at the Jalaali! Unfortunately, the test is currently failing based on the new formatter string. Would you be able to take a quick look and either update the formatter string or the test? Much appreciated :)

@philipbulley
Copy link
Contributor Author

@dmtrKovalenko, thanks for reviewing!

And also what was the motivation of updating example comments?

The previous examples were inaccurate so (in most cases) I have aligned the examples with the test assertions. For example:

Previous fullDate example docs:

/** Localized full date, useful for accessibility @example "January 1st, 2019" */
fullDate: TLibFormatToken;

Test assertion (unchanged):

${"fullDate"} | ${"Feb 1, 2020"} | ${"1 февр. 2020 г."}

Note that the month abbreviation is used, whereas the docs show that the full month is used. This inaccuracy is a show stopper for a11y text-to-speech, hence the update.

I'll comment on each change with the reason for the change (as some vary). Please let me know if there are any issues with any of the individual changes. Thanks!

Copy link
Contributor Author

@philipbulley philipbulley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rationale for individual doc changes...

export interface DateIOFormats<TLibFormatToken = string> {
/** Localized full date, useful for accessibility @example "January 1st, 2019" */
/** Localized full date @example "Jan 1, 2019" */
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prev example was inaccurate and did not match test assertion

normalDate: TLibFormatToken;
/** Date format string with weekday, month and day of month @example "Wed, Jan 1st" */
/** Date format string with weekday, month and day of month @example "Wed, Jan 1" */
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prev example was inaccurate and did not match test assertion

normalDateWithWeekday: TLibFormatToken;
/** Shorter day format @example "1 January" */
/** Shorter day format @example "Jan 1" */
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prev example was inaccurate and did not match test assertion

@@ -15,37 +21,41 @@ export interface DateIOFormats<TLibFormatToken = string> {
monthShort: TLibFormatToken;
/** Short month format string @example "January 2018" */
monthAndYear: TLibFormatToken;
/** Month with date format string @example "January 1st" */
/** Month with date format string @example "January 1" */
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prev example was inaccurate and did not match test assertion

dayOfMonth: TLibFormatToken;
/** Hours format string @example "11" */
hours12h: TLibFormatToken;
/** Hours format string @example "23" */
hours24h: TLibFormatToken;
/** Minutes format string @example "59" */
/** Minutes format string @example "44" */
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aligned with test assertion (no real need in this case, but why not 😄 ).

fullTime24h: TLibFormatToken;
/** Date & time format string with localized time @example "2018, Jan 1st 11:44 PM" */
/** Date & time format string with localized time @example "Jan 1, 2018 11:44 PM" */
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prev example was inaccurate and did not match test assertion

fullDateTime24h: TLibFormatToken;
/** Localized keyboard input friendly date format @example "2019/01/01" */
/** Localized keyboard input friendly date format @example "02/13/2020 */
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prev example was inaccurate for en-US. However, I've deviated from the test assertion to better imply the mm/dd/yyyy order here (ie. 13 implies dd as cannot be mm).

keyboardDate: TLibFormatToken;
/** Localized keyboard input friendly date/time format @example "2019/01/01 23:44" */
/** Localized keyboard input friendly date/time format @example "02/13/2020 23:44" */
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prev example was inaccurate for en-US. However, I've deviated from the test assertion to better imply the mm/dd/yyyy order here (ie. 13 implies dd as cannot be mm).

keyboardDateTime: TLibFormatToken;
/** Not Localized keyboard input friendly date/time 12h format @example "2019/01/01 11:44 PM" */
/** Partially localized keyboard input friendly date/time 12h format @example "02/13/2020 11:44 PM" */
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prev example was inaccurate for en-US. However, I've deviated from the test assertion to better imply the mm/dd/yyyy order here (ie. 13 implies dd as cannot be mm).

I've also changed Not Localized to Partially localized to better reflect the use of the localized formatter for the date part.

keyboardDateTime12h: TLibFormatToken;
/** Not localized keyboard input friendly date/time 24h format @example "2019/01/01 23:44" */
/** Partially localized keyboard input friendly date/time 24h format @example "02/13/2020 23:44" */
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prev example was inaccurate for en-US. However, I've deviated from the test assertion to better imply the mm/dd/yyyy order here (ie. 13 implies dd as cannot be mm).

I've also changed Not Localized to Partially localized to better reflect the use of the localized formatter for the date part.

@dmtrKovalenko
Copy link
Owner

What the status of this PR? CI is failing. Would you be able to finish it?
If no please allow changes from maintainers and I will finish it by myself, thx!

@philipbulley
Copy link
Contributor Author

philipbulley commented Jul 1, 2020

@dmtrKovalenko the failing test is due to the Jalaali change by @c0m1t (I've requested they take a look). If you're confident enough to fix it, please do, either:

  1. The formatter string should be changed to match the assertion
  2. OR the assertion should be updated to match the formatter string

As I don't read the language, I can't tell which of these is correct.

ALSO:
@c0m1t suggests that the already existing fullDate and fullDateTime are incorrect too but correcting it would represent a breaking change. It's worth noting that after @c0m1t's change, fullDate and fullDateWithWeekday don't use the same ordering:

fullDate: "jYYYY, jMMMM Do",  // year at beginning with comma
fullDateWithWeekday: "dddd Do jMMMM jYYYY",  // year at end, no comma

🤷‍♂️ 🤷‍♂️ 🤷‍♂️ 😄

(Btw... Allow edits by maintainers has been checked since PR creation, is it not allowing you to commit?)

@c0m1t
Copy link
Contributor

c0m1t commented Jul 2, 2020

@c0m1t thanks for taking a look at the Jalaali! Unfortunately, the test is currently failing based on the new formatter string. Would you be able to take a quick look and either update the formatter string or the test? Much appreciated :)

I forgot , after day name, I updated the formatter string.

I don't know if people use the fullDate format as it is in code (month before day of month), but as a native speaker I never heard it in that order, it is always day of month before month. If there has not been any issues or pull requests about this format yet, it probably means it is fine (it might be better to avoid breaking changes).

But this is now how we made date-io/date-fns-jalali, we always put day of month before month.

@dmtrKovalenko
Copy link
Owner

I am not speaking those languages too, so I`d prefer just fix the tests as is (already done it) and wait for somebody (cc @c0m1t 🙏) open a PR that fixes translations...

@dmtrKovalenko dmtrKovalenko merged commit 6c02179 into dmtrKovalenko:master Jul 6, 2020
@dmtrKovalenko
Copy link
Owner

Thanks @philipbulley for your awesome input! ❤️

@philipbulley
Copy link
Contributor Author

@dmtrKovalenko no probs, it's my pleasure 👍 Thanks also to @c0m1t !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants