Fixed `type` date formatting in `econometrics` menu
Description
- [x] Added code to detect column date type and assign a date format in the
call_loadfunction ineconometrics_controller.py. - [x] #4713
- [x] Fixed date type

- [x] To add stability to the command.
- [x] No dependency change.
How has this been tested?
Tested by running the command with different datasets in the terminal.
- [x] Make sure affected commands still run in terminal
- [x] Ensure the SDK still works
- [x] Check any related reports
Checklist:
- [x] I have adhered to the GitFlow naming convention and my branch name is in the format of
feature/feature-nameorhotfix/hotfix-name. - [x] Update our documentation following these guidelines. Update any user guides that are affected by the changes.
- [x] Update our tests following these guidelines.
- [x] Make sure you are following our CONTRIBUTING guidelines.
- [x] If a feature was added make sure to add it to the corresponding integration test script.
Others
- [x] I have performed a self-review of my own code.
- [x] I have commented my code, particularly in hard-to-understand areas.
@deeleeramone please review and let me know your thoughts on this.
Codecov Report
Patch coverage: 40.44% and project coverage change: -0.16 :warning:
Comparison is base (
a1aff50) 58.43% compared to head (016b663) 58.28%.
Additional details and impacted files
@@ Coverage Diff @@
## develop #4742 +/- ##
===========================================
- Coverage 58.43% 58.28% -0.16%
===========================================
Files 588 588
Lines 53608 53616 +8
===========================================
- Hits 31328 31249 -79
- Misses 22280 22367 +87
| Impacted Files | Coverage Δ | |
|---|---|---|
| openbb_terminal/core/plots/backend.py | 42.07% <0.00%> (-1.29%) |
:arrow_down: |
| openbb_terminal/core/plots/plotly_helper.py | 73.73% <ø> (ø) |
|
| openbb_terminal/core/sdk/sdk_init.py | 92.75% <ø> (ø) |
|
| openbb_terminal/forecast/forecast_controller.py | 1.12% <0.00%> (ø) |
|
| openbb_terminal/helper_funcs.py | 49.75% <0.00%> (-0.38%) |
:arrow_down: |
| openbb_terminal/reports/reports_controller.py | 75.00% <ø> (ø) |
|
| terminal.py | 0.00% <0.00%> (ø) |
|
| openbb_terminal/terminal_helper.py | 32.03% <21.42%> (-0.71%) |
:arrow_down: |
| ...enbb_terminal/core/log/generation/custom_logger.py | 50.00% <33.33%> (-4.55%) |
:arrow_down: |
| ...b_terminal/econometrics/econometrics_controller.py | 46.56% <44.73%> (-0.85%) |
:arrow_down: |
| ... and 7 more |
... and 6 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
@deeleeramone thank you for your review. I will find a solution and fix it by today.
While working on the issue today, I found out an issue with the to_json() function in the pandas API.
It seems that the date_format parameter has epoch type by default so it causes the date column to be dumped as UNIX timestamp in json file.
The second type is iso(ISO8601 format). However this means the date column will be formatted as %Y-%m-%dT%H:%M:%S.
I will try to find a workaround to this problem.
The solution to modify the backend.py file needs to be reversed, this impacts every part of the terminal instead of being a targeted repair within the menu. This file does not need to be touched. The dataframes can be modified within the individual files of the econometrics folder, like
econometrics_modelandeconometrics_view.When I attempt to set a multi-index, it appears to "set", but then
showgives an error:(🦋) /econometrics/ $ index ccard -i age,income Successfully updated 'ccard' index to be 'age, income' (🦋) /econometrics/ $ show Error: cannot insert income, already exists (🦋) /econometrics/ $ show ccard Error: cannot insert income, already exists (🦋) /econometrics/ $
This is a bug I believe. I switched to the develop branch and used the same commands, and got the same error.
@deeleeramone can you please confirm if the problem arises without the modified code?
This was fixed in #4848, so closing this PR. Thanks, @the-praxs!