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

Implement library to format time/dates for international users. #2075

Merged
merged 4 commits into from
Mar 26, 2021

Conversation

npsedhain
Copy link
Contributor

Details

  • Added a first parameter to the two exposed functions in the DateUtils library, timestampToDateTime and timestampToRelative.
  • Replaced the timestampToRelative function implementation with moment().fromNow() method.
  • Implemented the timestampToDateTime function with the moment calendar() method with the exact configuration as that of the current implementation in Expensify.
  • Both the methods are locale-aware.

Fixed Issues

#1856

Tests

  1. Go to the main chat page of the application and select any conversation.
  2. Have a conversation and check the date-time implementation passing multiple locales.

Tested On

  • Web
  • Mobile Web
  • Desktop
  • iOS
  • Android

Screenshots

Web

image

Mobile Web

image

Desktop

image

iOS

Simulator Screen Shot - iPhone 11 - 2021-03-25 at 12 20 26

Android

image

@npsedhain npsedhain requested a review from a team as a code owner March 25, 2021 06:36
@github-actions
Copy link
Contributor

github-actions bot commented Mar 25, 2021

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

@botify botify requested review from joelbettner and removed request for a team March 25, 2021 06:36
@npsedhain
Copy link
Contributor Author

I have read the CLA Document and I hereby sign the CLA

@npsedhain
Copy link
Contributor Author

npsedhain commented Mar 25, 2021

Hey, @iwiznia, as per your suggestions, I have not imported any locale files and just laid out the groundwork. So, in order for various locales to work, we need to import that manually for now. Let me know if you have any other suggestions.

Note: I used locale fr and imported it while I was testing this.

@npsedhain
Copy link
Contributor Author

recheck

1 similar comment
@npsedhain
Copy link
Contributor Author

recheck

}

if (includeTimeZone) {
retVal = 'timeZone';
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this going to be equivalent to what we had? Before we appended the timezone to the format ie: Yesterday at 10:20 PST but now it seems we will return a full date when the includeTimeZone param is true, no?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think that what we want is:

  • Move this override outside this function
  • Remove the timeZone handling from it
  • After computing the calendar date, if includeTimeZone was passed, append the timezone to the generated string.

Right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Aaahh, you are correct! Thanks, will make the changes and push.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated :)

}
function timestampToDateTime(locale, timestamp, includeTimeZone = false) {
const date = getLocalMomentFromTimestamp(locale, timestamp);
const TZ = '[UTC]Z';
Copy link
Contributor

Choose a reason for hiding this comment

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

IMO it is clearer if you do this

Suggested change
const TZ = '[UTC]Z';
const TZ = includeTimeZone ? ' [UTC]Z' : '';

Then remove the if (includeTimeZone) { below and in each of the calendar key options do for example [Today at] LT${TZ} and remove the call to calendar that does not include ${TZ}.
Also, I think that our guidelines say this should be named tz?

Copy link
Contributor Author

@npsedhain npsedhain Mar 26, 2021

Choose a reason for hiding this comment

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

Goshhh! Why didn't I think of that, I made the requested change. Let me know if there is anything else.

* @param {Number} timestamp
*
* @returns {Moment}
*
* @private
*/
function getLocalMomentFromTimestamp(timestamp) {
function getLocalMomentFromTimestamp(locale, timestamp) {
moment.locale(locale);
Copy link
Contributor

Choose a reason for hiding this comment

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

If I understand correctly, the modal.locale method takes a language (like English = "en"). Calling the variable that we pass to it locale is confusing.

I think we should rename the variable name locale to lang just for clarity. That way, when you're calling something like timestampToDateTime you know the first argument that you have to pass is a language and not a location.

Copy link
Contributor

Choose a reason for hiding this comment

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

No, locale is the better name, since this is not a language, but a locale, which is something like en-US.

Copy link
Contributor

@joelbettner joelbettner Mar 26, 2021

Choose a reason for hiding this comment

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

Really? Because we are only call it using a language - 'en'.

{DateUtils.timestampToDateTime('en', props.timestamp)}

Either way, it's not a biggie. I just think it will end up being a bit confusing.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, that's just an example so this PR could be tested. We will be replacing that call with the preferred locale later.

@joelbettner joelbettner merged commit ee11bcb into Expensify:master Mar 26, 2021
@OSBotify
Copy link
Contributor

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

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