[HOLD for payment 2024-01-24] [$500] IOU - The date does not change and a message with incorrect dates is added #33248

lanitochka17 · 2023-12-18T17:10:00Z

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

Version Number: 1.4.13-8
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Issue found when executing PR #33174

Action Performed:

Go to staging.new.expensify.com
Navigate to the created expense details page (or create one)
Click on the date
Change it once

Expected Result:

Verify the date is changed, and a proper message is added, e.g. changed the date to 2023-12-17 (previously 2023-12-18)

Actual Result:

The date does not change and a message with incorrect dates is added

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

Screenshots/Videos

Add any screenshot/video evidence

Bug6318356_1702919179197.Recording__743.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01a1217caf58eef97c
Upwork Job ID: 1736795974579576832
Last Price Increase: 2023-12-18
Automatic offers:

getusha | Reviewer | 28070620
wlegolas | Contributor | 28070621

melvin-bot · 2023-12-18T17:10:05Z

Triggered auto assignment to @dylanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

melvin-bot · 2023-12-18T17:10:05Z

Job added to Upwork: https://www.upwork.com/jobs/~01a1217caf58eef97c

melvin-bot · 2023-12-18T17:10:07Z

Bug0 Triage Checklist (Main S/O)

This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
This bug is not a duplicate report (check E/App issues and #expensify-bugs)
- If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
This bug is reproducible using the reproduction steps in the OP. S/O
- If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
- If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
This issue is filled out as thoroughly and clearly as possible
- Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

melvin-bot · 2023-12-18T17:10:11Z

Triggered auto assignment to Contributor-plus team member for initial proposal review - @getusha (External)

abzokhattab · 2023-12-18T17:16:56Z

Issue is not reproducible on my account on staging

neoneww · 2023-12-18T17:37:49Z

Issue is not reproducible on my account on staging

melvin-bot · 2023-12-18T17:37:52Z

📣 @neoneww! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

Make sure you've read and understood the contributing guidelines.
Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

unidev727 · 2023-12-18T17:40:29Z

Proposal

from: @unicorndev-727

Please re-state the problem that we are trying to solve in this issue.

Previously created date doesn't show correctly.

What is the root cause of that problem?

The root cause is that we didn't consider timezone when creating date here

App/src/libs/ReportUtils.ts

Line 2089 in bb6bc9c

    
           formattedOldCreated = format(formattedOldCreated, CONST.DATE.FNS_FORMAT_STRING);

What changes do you think we should make in order to solve the problem?

We should update this line to.

formattedOldCreated = reportActionOriginalMessage?.oldCreated ? reportActionOriginalMessage?.oldCreated : format(new Date(), CONST.DATE.FNS_FORMAT_STRING);

What alternative solutions did you explore? (Optional)

We need to save created and old created in originMessage in "yyyy-MM-dd'T'HH:mm:ss'Z'" when creating and updating reportAction.

lanitochka17 · 2023-12-18T17:40:53Z

Hello
This issue can be reproduced for USA location

melvin-bot · 2023-12-18T17:53:55Z

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

mkhutornyi · 2023-12-18T17:55:22Z

Proposal

Please re-state the problem that we are trying to solve in this issue.

IOU - The date does not change and a message with incorrect dates is added
This happens only for users who are in negative timezone (GMT -x, not GMT +x)

What is the root cause of that problem?

App/src/libs/ReportUtils.ts

Line 2126 in e17c313

    
           let formattedOldCreated: Date | string = new Date(reportActionOriginalMessage?.oldCreated ? reportActionOriginalMessage.oldCreated : 0);

(Edit: now this is moved to here:

App/src/libs/ModifiedExpenseMessage.ts

Lines 149 to 150 in 7b836cf

    
           let formattedOldCreated: Date | string = new Date(reportActionOriginalMessage?.oldCreated ? reportActionOriginalMessage.oldCreated : 0); 
        
           formattedOldCreated = format(formattedOldCreated, CONST.DATE.FNS_FORMAT_STRING);

)

Here, reportActionOriginalMessage.oldCreated doesn't have any timezone info (i.e. 2022-12-01)
and new Date(reportActionOriginalMessage.oldCreated) parses date as GMT and resets date based on user timezone (i.e. if user timezone is GMT-4: Tue Nov 30 2022 20:00:00 GMT-0400)
So date is always 1 day behind

What changes do you think we should make in order to solve the problem?

use parseISO from date-fns

        let formattedOldCreated: Date | string = reportActionOriginalMessage?.oldCreated ? parseISO(reportActionOriginalMessage.oldCreated) : new Date();

We already applied same solution in other places (#30845, #30923)

xtabbas · 2023-12-18T20:32:35Z

Contributor details
Your Expensify account email: [email protected]
Upwork Profile Link: https://www.upwork.com/freelancers/touqeera21

melvin-bot · 2023-12-18T20:32:37Z

⚠️ Missing/invalid email or upwork profile link. Please make sure you add both your Expensify email and Upwork profile link in the format specified.

xtabbas · 2023-12-18T20:36:38Z

Contributor details
Your Expensify account email: [email protected]
Upwork Profile Link: https://www.upwork.com/freelancers/touqeera21

melvin-bot · 2023-12-18T20:36:41Z

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

wlegolas · 2023-12-19T01:43:36Z

Proposal

Please re-state the problem that we are trying to solve in this issue.

IOU - The date does not change and a message with incorrect dates is added

What is the root cause of that problem?

The problem is related to the process of creating and formatting the modified date because it created a Date object using the current local time, that way when formatting the date the timezone is applied according to the current environment.

Note: people east of GMT (most non-US) may not see this bug because new Date() moves the timezone forward for their local time, so the date may not change.

There is a condition in the ReportActionItem component to show the modified created date:

App/src/pages/home/report/ReportActionItem.js

Lines 429 to 431 in 4a9914f

    
           } else if (props.action.actionName === CONST.REPORT.ACTIONS.TYPE.MODIFIEDEXPENSE) { 
        
               children = <ReportActionItemBasicMessage message={ReportUtils.getModifiedExpenseMessage(props.action)} />; 
        
           } else {

As you can see, the message property receives the value to be displayed, this value is provided by the method getModifiedExpenseMessage from the ReportUtils, to generate the modified created data in the format YYYY-MM-DD (variable formattedOldCreated), first is created a Date object passing the oldCreated value, and after that is called the method format to apply the desired format.

App/src/libs/ReportUtils.ts

Lines 2123 to 2130 in 4a9914f

    
           const hasModifiedCreated = reportActionOriginalMessage && 'oldCreated' in reportActionOriginalMessage && 'created' in reportActionOriginalMessage; 
        
           if (hasModifiedCreated) { 
        
               // Take only the YYYY-MM-DD value as the original date includes timestamp 
        
               let formattedOldCreated: Date | string = new Date(reportActionOriginalMessage?.oldCreated ? reportActionOriginalMessage.oldCreated : 0); 
        
               formattedOldCreated = format(formattedOldCreated, CONST.DATE.FNS_FORMAT_STRING); 
        
               return getProperSchemaForModifiedExpenseMessage(reportActionOriginalMessage?.created ?? '', formattedOldCreated?.toString?.(), Localize.translateLocal('common.date'), false); 
        
           }

In this case, the oldCreated information has only the date information, for example "2023-10-23", and when we create a new date passing only the date information will be created a new date with the time information according to the current environment.

For example, the oldCreated value is "2023-10-23", when creating the date using the new Date(), the date will be "Sun Oct 22 2023 21:00:00 GMT-0300 (Brasilia Standard Time)", in my case was removed 3 hours from the modified date, that's why the result is always reduced by one.

What changes do you think we should make in order to solve the problem?

We should use the same approach used in this issue #30303, using the method formatWithUTCTimeZone from DateUtils to format the oldCreated to avoid the issues with the time zone and also try to add some Unit Tests to make sure the scenarios are working as expected.

Here you can see the formatWithUTCTimeZone method content:

App/src/libs/DateUtils.ts

Lines 654 to 669 in 4a9914f

    
           /** 
        
            * 
        
            * Get a date and format this date using the UTC timezone. 
        
            * param datetime 
        
            * param dateFormat 
        
            * returns If the date is valid, returns the formatted date with the UTC timezone, otherwise returns an empty string. 
        
            */ 
        
           function formatWithUTCTimeZone(datetime: string, dateFormat: string = CONST.DATE.FNS_FORMAT_STRING) { 
        
               const date = new Date(datetime); 
        
               if (isValid(date)) { 
        
                   return tzFormat(utcToZonedTime(date, 'UTC'), dateFormat); 
        
               } 
        
               return ''; 
        
           }

Here's an example of how we can change the code to fix this issue:

function getModifiedExpenseMessage(reportAction: OnyxEntry<ReportAction>): string | undefined {
    ...
    if (reportActionOriginalMessage?.oldCreated && reportActionOriginalMessage?.created) {
        const formattedOldCreated = DateUtils.formatWithUTCTimeZone(reportActionOriginalMessage?.oldCreated, CONST.DATE.FNS_FORMAT_STRING);

        return getProperSchemaForModifiedExpenseMessage(reportActionOriginalMessage?.created, formattedOldCreated, Localize.translateLocal('common.date'), false);
    }
    ...
}

Note: with this suggestion above we can improve the type checking, avoiding passing a default value (in this case Zero here at the end of the line) if reportActionOriginalMessage?.oldCreated is undefined, and also avoiding to pass an empty string if reportActionOriginalMessage?.created is undefined.

What alternative solutions did you explore? (Optional)

N/A

POC

poc-issue-33248.mp4

melvin-bot · 2023-12-19T17:01:55Z

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

dylanexpensify · 2023-12-20T09:28:46Z

@getusha mind giving an update?

getusha · 2023-12-20T15:41:04Z

Thanks everyone for the proposals.
the detailed RCA and proposal provided by @wlegolas Looks good to me.
🎀 👀 🎀 C+ Reviewed!

mkhutornyi · 2023-12-25T06:42:19Z

I already tried to find other places. I hope this would be the last one 🙏 as part of moment > date-fns migration refactor

wlegolas · 2023-12-26T10:31:27Z

I'm unable to reproduce this issue. Can you try again please @lanitochka17?

Hi @youssef-lr maybe the reason you weren't able to reproduce this bug is related to the note I put in my #33248 (comment)

Note: people east of GMT (most non-US) may not see this bug because new Date() moves the timezone forward for their local time, so the date may not change

wlegolas · 2023-12-27T00:24:53Z

Ah I see. Can you check please if there are other places where we could fix this as well?

Hi, @youssef-lr I found two places with the code that could possibly have the same time zone issue.

In the file ModifiedExpenseMessage, we have the same problem related to this issue, if you see the code below, the code is using the information reportActionOriginalMessage?.oldCreated that is a date with only the date information.

App/src/libs/ModifiedExpenseMessage.ts

Lines 146 to 160 in 4cfb8a2

    
           const hasModifiedCreated = reportActionOriginalMessage && 'oldCreated' in reportActionOriginalMessage && 'created' in reportActionOriginalMessage; 
        
           if (hasModifiedCreated) { 
        
               // Take only the YYYY-MM-DD value as the original date includes timestamp 
        
               let formattedOldCreated: Date | string = new Date(reportActionOriginalMessage?.oldCreated ? reportActionOriginalMessage.oldCreated : 0); 
        
               formattedOldCreated = format(formattedOldCreated, CONST.DATE.FNS_FORMAT_STRING); 
        
               buildMessageFragmentForValue( 
        
                   reportActionOriginalMessage?.created ?? '', 
        
                   formattedOldCreated, 
        
                   Localize.translateLocal('common.date'), 
        
                   false, 
        
                   setFragments, 
        
                   removalFragments, 
        
                   changeFragments, 
        
               ); 
        
           }

Here in this image, we can see the value format in the reportActionOriginalMessage?.oldCreated property.

The other place is in the DateUtils file where we can see many places creating a new Date object with the statement new Date(someDateStringValue). I tried to check in the places where the methods that use the new Date() to validate if the date string is in the correct format, and looks like these methods receive a data string with the correct format.

If you have any questions, please let me know.

mkhutornyi · 2023-12-27T00:34:04Z

Ah I see. Can you check please if there are other places where we could fix this as well?

Hi, @youssef-lr I found two places with the code that could possibly have the same time zone issue.

In the file ModifiedExpenseMessage, we have the same problem related to this issue, if you see the code below, the code is using the information reportActionOriginalMessage?.oldCreated that is a date with only the date information.

App/src/libs/ModifiedExpenseMessage.ts

Lines 146 to 160 in 4cfb8a2

const hasModifiedCreated = reportActionOriginalMessage && 'oldCreated' in reportActionOriginalMessage && 'created' in reportActionOriginalMessage;

if (hasModifiedCreated) {

// Take only the YYYY-MM-DD value as the original date includes timestamp

let formattedOldCreated: Date | string = new Date(reportActionOriginalMessage?.oldCreated ? reportActionOriginalMessage.oldCreated : 0);

formattedOldCreated = format(formattedOldCreated, CONST.DATE.FNS_FORMAT_STRING);

buildMessageFragmentForValue(

reportActionOriginalMessage?.created ?? '',

formattedOldCreated,

Localize.translateLocal('common.date'),

false,

setFragments,

removalFragments,

changeFragments,

);

}

This is what we're trying to fix here. Your proposal is deprecated. Code was moved in #30603

melvin-bot · 2023-12-27T04:58:18Z

📣 @getusha 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

melvin-bot · 2023-12-27T04:58:22Z

📣 @wlegolas 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

youssef-lr · 2023-12-27T04:58:38Z

@wlegolas can we please standardize using the same format function everywhere?

wlegolas · 2023-12-27T23:59:31Z

@wlegolas can we please standardize using the same format function everywhere?

Sure, I'll change the files to use the same function.

Thank you @youssef-lr for reviewed my proposal

wlegolas · 2023-12-28T03:08:32Z

Hi @youssef-lr, @getusha I created the PR #33688 with the changes.

Note: I didn't put the evidence for "Android: Native" because I've been having problems running the application in my simulator, but I'll generate this evidence and update the PR description.

When I was fixing this issue I realized that the code to format the oldCreated information was extracted from the src/libs/ReportUtils.ts file to this src/libs/ModifiedExpenseMessage.ts file through this PR #30603

With this change, I only need to fix the issue in the src/libs/ModifiedExpenseMessage.ts file.

If you have any questions or suggestions, feel free to bring them.

wlegolas · 2024-01-02T01:53:09Z

Hi @youssef-lr and @getusha I put the last evidence for Android Native.

I have a question about this implementation, in my tests, I noticed both dates created and oldCreated come from the backend in the format yyyy-mm-dd, this is the same format that I'm fixing to show the information without care about the timezone.

Do you know why we need to convert the value from the backend to a Date object and format this Date object to the format yyyy-mm-dd? Maybe there is a scenario for that, for example, old records may have an issue.

dylanexpensify · 2024-01-08T09:08:57Z

@getusha @youssef-lr mind confirming

melvin-bot · 2024-01-17T01:08:54Z

Reviewing label has been removed, please complete the "BugZero Checklist".

melvin-bot · 2024-01-17T01:08:58Z

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.25-10 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

Fix oldCreated date format when the created date was changed #33688

If no regressions arise, payment will be issued on 2024-01-24. 🎊

For reference, here are some details about the assignees on this issue:

@wlegolas requires payment automatic offer (Contributor)
@getusha requires payment automatic offer (Reviewer)

melvin-bot · 2024-01-17T01:08:59Z

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

[@getusha] The PR that introduced the bug has been identified. Link to the PR:
[@getusha] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
[@getusha] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
[@getusha] Determine if we should create a regression test for this bug.
[@getusha] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
[@dylanexpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

dylanexpensify · 2024-01-17T09:34:52Z

coming up!

dylanexpensify · 2024-01-23T13:21:45Z

tomorrow!

dylanexpensify · 2024-01-29T11:48:58Z

Payment summary:

Contributor: @wlegolas $500
Contributor+: @getusha $500

Please apply or request!

dylanexpensify · 2024-01-29T11:50:57Z

payments sent!

lanitochka17 added External Added to denote the issue can be worked on by a contributor Daily KSv2 Bug Something is broken. Auto assigns a BugZero manager. labels Dec 18, 2023

melvin-bot bot assigned dylanexpensify Dec 18, 2023

melvin-bot bot changed the title ~~IOU - The date does not change and a message with incorrect dates is added~~ [$500] IOU - The date does not change and a message with incorrect dates is added Dec 18, 2023

melvin-bot bot added the Help Wanted Apply this label when an issue is open to proposals by contributors label Dec 18, 2023

melvin-bot bot assigned getusha Dec 18, 2023

This comment was marked as resolved.

Sign in to view

kavimuru mentioned this issue Dec 18, 2023

Deploy Checklist: New Expensify 2023-12-14 #33072

Closed

77 tasks

situchan mentioned this issue Dec 19, 2023

ReportAction text for transactions edited in OldDot #30603

Merged

58 tasks

melvin-bot bot assigned youssef-lr Dec 20, 2023

youssef-lr assigned wlegolas Dec 27, 2023

melvin-bot bot removed the Help Wanted Apply this label when an issue is open to proposals by contributors label Dec 27, 2023

wlegolas mentioned this issue Dec 28, 2023

Fix oldCreated date format when the created date was changed #33688

Merged

51 tasks

melvin-bot bot added Reviewing Has a PR in review Weekly KSv2 and removed Daily KSv2 labels Dec 28, 2023

melvin-bot bot added Weekly KSv2 Awaiting Payment Auto-added when associated PR is deployed to production and removed Weekly KSv2 labels Jan 17, 2024

melvin-bot bot changed the title ~~[$500] IOU - The date does not change and a message with incorrect dates is added~~ [HOLD for payment 2024-01-24] [$500] IOU - The date does not change and a message with incorrect dates is added Jan 17, 2024

melvin-bot bot removed the Reviewing Has a PR in review label Jan 17, 2024

dylanexpensify closed this as completed Jan 29, 2024

[HOLD for payment 2024-01-24] [$500] IOU - The date does not change and a message with incorrect dates is added #33248

[HOLD for payment 2024-01-24] [$500] IOU - The date does not change and a message with incorrect dates is added #33248

Comments

lanitochka17 commented Dec 18, 2023 • edited by melvin-bot bot Loading

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

melvin-bot bot commented Dec 18, 2023

melvin-bot bot commented Dec 18, 2023

melvin-bot bot commented Dec 18, 2023

Bug0 Triage Checklist (Main S/O)

melvin-bot bot commented Dec 18, 2023

abzokhattab commented Dec 18, 2023

neoneww commented Dec 18, 2023

melvin-bot bot commented Dec 18, 2023

unidev727 commented Dec 18, 2023 • edited Loading

Proposal

Please re-state the problem that we are trying to solve in this issue.

What is the root cause of that problem?

What changes do you think we should make in order to solve the problem?

What alternative solutions did you explore? (Optional)

lanitochka17 commented Dec 18, 2023

This comment was marked as resolved.

melvin-bot bot commented Dec 18, 2023

mkhutornyi commented Dec 18, 2023 • edited Loading

Proposal

Please re-state the problem that we are trying to solve in this issue.

What is the root cause of that problem?

What changes do you think we should make in order to solve the problem?

xtabbas commented Dec 18, 2023

melvin-bot bot commented Dec 18, 2023

xtabbas commented Dec 18, 2023

melvin-bot bot commented Dec 18, 2023

wlegolas commented Dec 19, 2023 • edited Loading

Proposal

Please re-state the problem that we are trying to solve in this issue.

What is the root cause of that problem?

What changes do you think we should make in order to solve the problem?

What alternative solutions did you explore? (Optional)

melvin-bot bot commented Dec 19, 2023

dylanexpensify commented Dec 20, 2023

getusha commented Dec 20, 2023

mkhutornyi commented Dec 25, 2023

wlegolas commented Dec 26, 2023 • edited Loading

wlegolas commented Dec 27, 2023

mkhutornyi commented Dec 27, 2023

melvin-bot bot commented Dec 27, 2023

melvin-bot bot commented Dec 27, 2023

youssef-lr commented Dec 27, 2023

wlegolas commented Dec 27, 2023 • edited Loading

wlegolas commented Dec 28, 2023 • edited Loading

wlegolas commented Jan 2, 2024

dylanexpensify commented Jan 8, 2024

melvin-bot bot commented Jan 17, 2024

melvin-bot bot commented Jan 17, 2024

melvin-bot bot commented Jan 17, 2024

dylanexpensify commented Jan 17, 2024

dylanexpensify commented Jan 23, 2024

dylanexpensify commented Jan 29, 2024

dylanexpensify commented Jan 29, 2024

lanitochka17 commented Dec 18, 2023 •

edited by melvin-bot bot

Loading

unidev727 commented Dec 18, 2023 •

edited

Loading

mkhutornyi commented Dec 18, 2023 •

edited

Loading

wlegolas commented Dec 19, 2023 •

edited

Loading

wlegolas commented Dec 26, 2023 •

edited

Loading

wlegolas commented Dec 27, 2023 •

edited

Loading

wlegolas commented Dec 28, 2023 •

edited

Loading