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

Miscalculation of date boundary due to time zone differences #640

Closed
KomalJha01 opened this issue Nov 20, 2024 · 5 comments · Fixed by #641
Closed

Miscalculation of date boundary due to time zone differences #640

KomalJha01 opened this issue Nov 20, 2024 · 5 comments · Fixed by #641

Comments

@KomalJha01
Copy link

I've attached a PDF that explains that boundary cases of date are not handled correctly.
In my case, I want to calculate the Amount (Ask_Amount__c is the lookup on contact) on the contact which is N_YEARS_AGO so when I'm taking the boundary values of dates then It does not give the correct amount.

Further details are explained in the pdf.

_Miscalculation of Date Boundary due to Time Zone Differences (1).pdf

@KomalJha01 KomalJha01 changed the title Miscalculation of Date Boundary due to Time Zone Differences Miscalculation of date boundary due to time zone differences Nov 20, 2024
@jamessimone
Copy link
Owner

Thanks for the PDF. I will take a look!

@jamessimone
Copy link
Owner

@KomalJha01 can you clarify on the following sentence:

we replaced the usage of Datetime.newInstance() with Datetime.newInstanceGMT()

Is that in your own code, or within Apex Rollup? Not all date literals use GMT when calculating date boundaries (see the docs on this):

Each date literal represents a range of time relative to the current day. The exact start and stop of the range depends on the date literal and the locale of the user sending the query.

Thanks!

@KomalJha01
Copy link
Author

This is my own code.
Yes but when are calculating the range of date value within the boundaries then
dateVal > this.bound.dateGmt() && dateVal > this.ref.dateGmt();
And then .dateGMT() gives the time shift issue results in the wrong calculation.
image

@jamessimone
Copy link
Owner

Got it! I will get this fixed - I've had limited time this week but hoping to be able to dedicate a few hours tomorrow

@KomalJha01
Copy link
Author

Thanks!! @jamessimone

jamessimone added a commit that referenced this issue Nov 28, 2024
…n local time since they are always based off of the running user and their time zone
jamessimone added a commit that referenced this issue Dec 2, 2024
* Fixes #640 by properly ensuring RollupDateLiteral comparisons occur in local time since they are always based off of the running user and their time zone
* Fixes an issue brought up in #639 where scheduling a rollup can inadvertently exceed the max query rows
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 a pull request may close this issue.

2 participants