search

SCasanova / f1dataR

An R package to access Formula 1 Data from the Ergast API and the unofficial F1 data stream via the fastf1 python library.
https://scasanova.github.io/f1dataR/
Other
52 stars 5 forks source link

Fix season start date #227

Closed pbulsink closed 6 months ago

pbulsink commented 6 months ago

Per @jvalls99: https://github.com/SCasanova/f1dataR/discussions/226#discussioncomment-8648864

pbulsink commented 6 months ago

I'll try figure out how FastF1 does "current season" logic and match it.

pbulsink commented 6 months ago

FastF1 doesn't have a 'current' season feature (I'm happy to be corrected if I'm wrong).

We had considered using 01 February in the past as a default 'flip' if I recall, but the reality is that until Ergast updates their database with new season information, there's nothing to be extracted from there.

For example, until their database included the 2024 schedule there was no underlying structural way to pull data from 2024 Bahrain.

The speed of updating of Ergast is not in our control (and will change after this season, since it's deprecating (#222)), so the only effect is on the FastF1 functions with 'current' as a season parameter. You can avoid that by calling the specific season/year instead of using 'current'.

We should loosen the season check on fastf1 functions if it's between January & March/April.

SCasanova commented 6 months ago

Yes, I think loosening is the right move because even after Q, using the manual input season 2024 wouldn't work since we're checking Ergast for data. It also makes sense to start moving on from Ergast dependencies. I can take a look at that

pbulsink commented 6 months ago

Instead of checking against get_current_season(), you can likely get away with something like:

if(season > as.integer(format(Sys.Date(), "%Y"))){
   cli::cli_abort("{.arg season} cannot be in the future.")
}