-
Notifications
You must be signed in to change notification settings - Fork 1.9k
feat(formatDate): add locale option to be extensible for absolute format #19157
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(formatDate): add locale option to be extensible for absolute format #19157
Conversation
✅ Deploy Preview for v11-carbon-web-components ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for v11-carbon-react ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #19157 +/- ##
=======================================
Coverage 84.59% 84.59%
=======================================
Files 380 380
Lines 14471 14471
Branches 4771 4737 -34
=======================================
Hits 12242 12242
Misses 2074 2074
Partials 155 155 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dkaushik95 Can you add unit test coverage in absolute-test.js
?
Thanks for the review @nchevsky . I have addressed all the review comments. Can you re-review it? Thanks! |
timeZones.forEach((timeZone) => { | ||
const dtf = new Intl.DateTimeFormat(locale, { | ||
timeStyle: style, | ||
timeZone, | ||
}); | ||
const expectedOutput = dtf.format(date); | ||
|
||
test(`${style} with timeZone ${timeZone} → ${expectedOutput}`, () => { | ||
const actualOutput = absolute.formatTime(date, { | ||
locale, | ||
style, | ||
timeZone, | ||
}); | ||
expect(actualOutput).toBe(expectedOutput); | ||
}); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't put this within the timeStyle
loop, as (a) it multiplies the number of iterations 4 → 12 and (b) timeStyle
and timeZone
aren't dependent on each other.
We don't even need to test three different time zones, for timeZone
is simply passed through to Intl.DateTimeFormat
regardless of its value. Some alternatives, in ascending order of complexity:
- Test any two time zones so that, even if one happens to match the host's, the other won't; or
- spy on
Intl.DateTimeFormat
and simply assert thatabsolute.format*()
instantiated it with the giventimeZone
option; or - dynamically select a time zone other than the host's, and test just that one.
I'd personally go with # 2 as it's more of a true unit test, but seeing how none of the preexisting tests are written this way, it might be less controversial to stick with # 1.
Whichever you choose, please replicate to all tests. 🙏🏻
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, I chose the 1st option. I chose two timezones Tokyo
and UTC
so that it's always different for any host for at least one test. I also addressed the 2nd concern of using describe
for timeZones so it should be consistent across all tests. I was trying different approaches and accidentally added both approaches :)
This will how the tests would show up.
At the end there will be 2 test cases for each function (8 iterations in all)
@dkaushik95 I approved the PR and then realized we missed updating the documentation for the newly added option. Could you please add the relevant details to the README file? |
@preetibansalui Hello! I have made changes to add documentation to the readme. Can you give it a review? Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me—just a small spelling correction needed.
|
||
For `absolute` functions, you can provide `timeZone` as an optional property. | ||
This is usefull when (for example) you want to display utc time instead of a | ||
local timezone. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is useful when (for example) you want to display UTC time instead of a
local time zone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks! Fixed :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes, This LGTM 👍
0ce2c4e
Closes #
Currently
absolute.format*
doesn't work for our product since we allow users the option to switch to UTC time. AddingtimeZone
as a prop allows us to override the default timezone thatIntl
chooses.Changelog
New
Datetime.absolute
now allows you to choose atimeZone
which can be used to override the default timeZone while formatting datetime. This prop will be available to:formatTime
,formatTime
,format
, andformatRange
Testing / Reviewing
1744835151846
UTC