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

Inconsistent behavior of parse_date_time if time only provided #458

Closed
danaki opened this Issue Aug 17, 2016 · 5 comments

Comments

Projects
None yet
2 participants
@danaki

danaki commented Aug 17, 2016

> parse_date_time(c("3:15:00"), c("Ims"))
[1] "2016-08-17 03:15:00 UTC"
> parse_date_time(c("3:15:00"), c("Hms"))
[1] "-001-12-31 03:15:00 UTC"
> parse_date_time(c("3:15:00 AM"), c("Hmsp"))
[1] "2016-08-17 03:15:00 UTC"
> packageVersion("lubridate")
[1] ‘1.5.6

I guess that date part must be "-001-12-31" if not provided, not the current date.

@vspinu

This comment has been minimized.

Show comment
Hide comment
@vspinu

vspinu Aug 17, 2016

Member

None of your examples should have worked behause the formats are HMS not Hms. m is month. s is undefined.

I can reproduce the inconsistency but with a different result for the second case

parse_date_time(c("3:15:00"), c("HMS"))
[1] "0-01-01 03:15:00 UTC"

But I am not sure about this semantics though. I recall there has been a related discussion in one of the issues on missing components.

Why do you think 0-01-01 is a better default than the current date?

Member

vspinu commented Aug 17, 2016

None of your examples should have worked behause the formats are HMS not Hms. m is month. s is undefined.

I can reproduce the inconsistency but with a different result for the second case

parse_date_time(c("3:15:00"), c("HMS"))
[1] "0-01-01 03:15:00 UTC"

But I am not sure about this semantics though. I recall there has been a related discussion in one of the issues on missing components.

Why do you think 0-01-01 is a better default than the current date?

@vspinu

This comment has been minimized.

Show comment
Hide comment
@vspinu

vspinu Aug 17, 2016

Member

In any case, what you are trying to achieve is better done by hms

hms("3:15:00")
[1] "3H 15M 0S"

This is a periods that you should add to a date-time object.

Your examples will be throwing errors when I fix this issue, unless you can convince me that your usage pattern is worthwhile.

Member

vspinu commented Aug 17, 2016

In any case, what you are trying to achieve is better done by hms

hms("3:15:00")
[1] "3H 15M 0S"

This is a periods that you should add to a date-time object.

Your examples will be throwing errors when I fix this issue, unless you can convince me that your usage pattern is worthwhile.

@danaki

This comment has been minimized.

Show comment
Hide comment
@danaki

danaki Aug 18, 2016

Yep 0-01-01 is better undoubtedly. Sorry.

danaki commented Aug 18, 2016

Yep 0-01-01 is better undoubtedly. Sorry.

@danaki danaki closed this Aug 18, 2016

@vspinu vspinu reopened this Aug 18, 2016

@vspinu

This comment has been minimized.

Show comment
Hide comment
@vspinu

vspinu Aug 18, 2016

Member

I am keeping this open. There are multiple issues still to be fixed in your examples.

Member

vspinu commented Aug 18, 2016

I am keeping this open. There are multiple issues still to be fixed in your examples.

@danaki

This comment has been minimized.

Show comment
Hide comment
@danaki

danaki Aug 18, 2016

Ok, 0-01-01 is better than the current date just because the very same time will parse to new value every other day. In some cases that could lead to a problem of comparing such values if the sources are far in time. I guess 0-01-01 or any other default "zero" value would be more consistent.

danaki commented Aug 18, 2016

Ok, 0-01-01 is better than the current date just because the very same time will parse to new value every other day. In some cases that could lead to a problem of comparing such values if the sources are far in time. I guess 0-01-01 or any other default "zero" value would be more consistent.

@vspinu vspinu closed this in 1c5a655 Aug 18, 2016

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