Research Regression Tests / build (push) Has been cancelled
Python Virtual Environments / build (push) Has been cancelled
Benchmarks / build (push) Has been cancelled
Build & Test Lean / build (push) Has been cancelled
Regression Tests / build (push) Has been cancelled
* Update Future-cme-[*] and Future-cme-ES
Acoording to `pandas_market_calendars` there were some dates in
Future-cme-[*] who wasn't early_closes, so they needed to be removed
from there. On the other hand, the early closes list of Future-cme-ES were
shifted by 1 hour according to CME webpage. Besides, there were some
missing dates.
* Update CME Future entries in MHDB
* Rebase
* nit change
* Fix unit tests
* Resume after early close/halts
* Add missing dates in MHDB and fix bugs in it
* Fix bug, add more unit tests and add docs
* fix regression algos
* address required changes
* Update failing regression test stats
After debugging the tests it was found they were failing due to the last
change on SecurityExchangeHours.IsOpen(). That method wasn't taking into
account that even if there is a late open after an early close if the
timespan is after the early close but before the late open, the market
is still close.
* enhance solution
* Update and fix bugs in MHDB
* Address required changes and update stats
* Update stats after rebase
* Nit change
* Missing update to regression test
* Use MHDB instead of USHoliday for Expiration Dates
VIX expiry function now relies completely on MHDB. However, it had to be
created an entry in MHDB for VIX since there wasn't one for it. CBOE
webpage only provided 2023 holidays so only those dates were considered
in the Holidays entry in MHDB. Therefore, some unit tests failed so it
was necessary to change also the VIX entry in FuturesExpiryFunctionsTestData.xml.
* Remove Global.cs/USHolidays class
* Use a lazy implementation
* First draft of the solution
* Use MHDB in FuturesExpiryFunctions.cs
* Remove unused class and fix indentation errors
* Fix indentation errors
* Nit changes
* Merge branches 7501 and 7506
* Merge changes in 7501 and 7506
In order to check compatibility between those branches, a new branch
was created out of branch 7501 and then it was merged with branch 7506.
2 regression tests and 8 unit tests failed, the regression tests failed on
the DataPoint stats. On the other hand, the unit tests failed since the
default parameter UseEquityHoliday was removed from
FuturesExpirtyUtilityFunctions.AddBusinessDays() and from other methods in
the same class too.
* Add missing changes
* Remove repeated good fridays
* Address minor review
---------
Co-authored-by: Martin Molinero <martin.molinero1@gmail.com>
- Adjusting live stack to emit live auxiliary events based on factor files.
Updating existing tests
- Minor improvements for map & factor file provider daily refresh time.
Adding unit tests
Build & Test Lean / build (push) Has been cancelled
Regression Tests / build (push) Has been cancelled
* Move Aggregate Quote and Trade Bars to utils
* Add decimal and long overload to UnixTimeStampToDateTime
* Add Kraken OrderType check in CanSubmitOrder
* PR !5969 review fixes
Build & Test Lean / build (push) Has been cancelled
* Adds processed data directory to read price data from
* Make coarse universe generator look at data directory before failing to find daily data
* Set coarse generator output of missing daily file to debug log
* Add CoarseUniverseGenerator logs
* Fixes 100 nanosecond increment lookahead bias when parsing large numbers
* Whenever we parse a number that is has precision greater than
DateTime ticks (sub-100 nanoseconds), if we have nanoseconds
between [0, 1000), excluding numbers divisible by 100,
we will have leftover nanoseconds between [0, 100) nanoseconds, but
they won't be factored in to the DateTime calculation, since casting
to `long` only takes the integer component of the number, so we lose
the extra nanoseconds that came with the decimal, and time is set to
the "floored" value without those nanoseconds.
Since .NET `DateTime` type has a limitation of only being able
to represent time in increments of 100 nanoseconds, by not
considering the sub-100 nanoseconds, we introduce a look-ahead
bias of at most 100 nanoseconds/1 tick
* Misc adjustment to make method use `decimal` instead of `double`
for increased precision when parsing large numbers
* Changes CoinAPI data converter to support processing raw files in original directory structure and file name
* Removes Market requirement from CoinAPI data converter
* Remove timeout on decompression of raw AlgoSeek futures data
* Updates SEC downloader to use HttpClient where requests were failing
* For some unknown reason, valid requests to a valid URL were
failing when using WebClient. Changing our requester to
HttpClient fixes the issue, and enables us to leverage
async capabilities where applicable.
* Added fault tolerance to index file downloads, including a
rate limit in case we've been rate limited
* Further refactoring; catches 429 errors, adds missing rategate calls
* Replace all usage of WebClient, force retry for all failures
* Adds optional config value for Benzinga News API key in downloader
* Modifies Estimize Downloader api config name and fixes directory not found bug
* Refactor Estimize to speed up processing time
* Adds ticker limits if desired
* Misc. bug fixes, performance improvements, code cleanup
* Remove debug log statements leftover from previous commit
* Add support for non-tick Index resolutions in LeanDataWriter
* Empty commit
* Empty commit
* Empty commit
* Empty commit
* Empty commit
* Empty commit
* Lower requests/second for SEC downloader, add missing rategate call
Co-authored-by: Martin-Molinero <martin@quantconnect.com>
* regression tests
* fix: apply the same time convertion to history request time as for data time
* ver2
* fixup
* unit tests
* do not need this conversion because RoundDownInTimeZone returns in proper TZ
* comment
* requested changes
* refactoring
* more refactoring
* fix existing test: should return Sunday if open
* more symbols
* fix existing tests: submit new btcusd data
* fix
* add Cfd symbol
Fixes a bug where we were using the security's data resolution to compute
the insight's close time. This led a case such as insight.Period == 20days
to step 20days worth of tradable minutes (assuming minute data resolution),
yielding a close time that was very far in the future.
We also add different means of specifying an insight's period/close time:
1. Specify insight period as a TimeSpan and we compute close time
2. Specify insight period and a resolution and bar count and we compute close time
3. Specify insight close time local directly and we compute the insight period
The key here is maintaining consistency between the three different approaches
which is heavily validated with the corresponding unit tests.
Edits also made to trust the insight's close time as the analysis end time in
the case where the analysis period == insight period (extra analysis period = 0).
Given the current setup (extra analysis period == 0), this guarantees that close
and analysis end times are equivalent.
Regression statistics were updated and expectedly we get many more insights that
have completed analysis, and as such, average scores have also changed.
Jhonathan Abreu