Issue 2233: Remove use of native date objects in DB#2235
Merged
Conversation
…alues instead of one date object
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
connects #2233
This pull request focuses on improving date handling throughout the analysis and data migration logic. The main changes include standardizing how dates are processed (favoring local time over UTC), updating data migration routines to add explicit
month,year, anddayfields, and utilizing helper functions for date comparison and predictor data selection. These changes enhance consistency and reliability in date-related calculations and data migrations.Date Handling Standardization:
Replaced usage of
getUTCFullYear()andgetUTCMonth()withgetFullYear()andgetMonth()across multiple analysis classes to ensure local time is used for year and month calculations. This affects classes such asAnnualAnalysisSummaryDataClass,MonthlyAccountAnalysisClass,MonthlyAnalysisSummaryClass, and others. [1] [2] [3] [4] [5] [6] [7]Updated filtering and data grouping logic to use helper functions like
checkSameMonthfor consistent month comparisons, replacing direct property checks. [1] [2] [3] [4] [5]Data Migration and Enrichment:
Enhanced data migration routines to populate and persist
month,year, anddayfields inpredictorDataandmeterDatarecords if not already set, marking them as migrated. This ensures that all records have explicit date components for future processing. [1] [2]Modified the signature of
setPredictorDataV2to accept an additional boolean parameter, likely to control migration behavior.Predictor Data Handling Improvements:
Changed the way the latest predictor data is determined by using the new
getLatestPredictorDatahelper instead of_.maxBy, and ensured that date extraction usesgetDateFromPredictorDatafor consistency. [1] [2]Updated filtering of predictor data for a given month to use the explicit
yearandmonthfields, improving reliability over date string parsing. [1] [2]Imports and Dependency Updates:
checkSameMonth,getDateFromPredictorData,getLatestPredictorData) in relevant analysis classes to support the above logic. [1] [2] [3] [4] [5]These changes collectively improve the robustness and consistency of date-related logic throughout the application.