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

Provide an option to avoid format guesser #308

Closed
robertzk opened this Issue Mar 17, 2015 · 6 comments

Comments

Projects
None yet
3 participants
@robertzk

robertzk commented Mar 17, 2015

Maybe we could give all the parsing functions that rely on the guesser an additional option to use a full scan, with the user knowing it will impact performance? This will avoid issues like #307

@vspinu

This comment has been minimized.

Show comment
Hide comment
@vspinu

vspinu Mar 17, 2015

Member

👍

  • Add train option to parse_date_time and make no-training the default.
  • Ignore training option when only one order has been supplied.
Member

vspinu commented Mar 17, 2015

👍

  • Add train option to parse_date_time and make no-training the default.
  • Ignore training option when only one order has been supplied.

@vspinu vspinu added the enhancement label Mar 17, 2015

@peterhurford

This comment has been minimized.

Show comment
Hide comment
@peterhurford

peterhurford commented Mar 17, 2015

👍

@vspinu

This comment has been minimized.

Show comment
Hide comment
@vspinu

vspinu Apr 23, 2015

Member

I am afraid it's not possible to avoid sparse guesser because of the flexibility of the "orders" versus the sprtime "formats". When you supply ymd it can match "12-12-12" or "2012-12-12" or "121212" etc. You cannot solve that without training. So I am afraid you just have to use alternative functions (sptrtime, fast_sptrtime or parse_date_time2) that don't perform guessing.

I have now documented this in the parse_date_time documentation.

Member

vspinu commented Apr 23, 2015

I am afraid it's not possible to avoid sparse guesser because of the flexibility of the "orders" versus the sprtime "formats". When you supply ymd it can match "12-12-12" or "2012-12-12" or "121212" etc. You cannot solve that without training. So I am afraid you just have to use alternative functions (sptrtime, fast_sptrtime or parse_date_time2) that don't perform guessing.

I have now documented this in the parse_date_time documentation.

@vspinu

This comment has been minimized.

Show comment
Hide comment
@vspinu

vspinu Oct 31, 2015

Member

I came back on this one. There is now an option exact=TRUE that treats orders as strptime formats and doesn't perform any training or guessing.

Member

vspinu commented Oct 31, 2015

I came back on this one. There is now an option exact=TRUE that treats orders as strptime formats and doesn't perform any training or guessing.

@peterhurford

This comment has been minimized.

Show comment
Hide comment
@peterhurford

peterhurford Oct 31, 2015

👍 Awesome!

peterhurford commented Oct 31, 2015

👍 Awesome!

@vspinu

This comment has been minimized.

Show comment
Hide comment
@vspinu

vspinu May 7, 2017

Member

In next version parse_date_time gained train=TRUE and drop=FALSE arguments. As you could guess, formats are no longer dropped. Similar issues should not occur anymore.

Member

vspinu commented May 7, 2017

In next version parse_date_time gained train=TRUE and drop=FALSE arguments. As you could guess, formats are no longer dropped. Similar issues should not occur anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment