Inconsistent behavior of parse_date_time if time only provided

[danaki]

> 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]

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]

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]

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.

[vspinu]

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]

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

[danaki]

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

[vspinu]

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

[vspinu]

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

[danaki]

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]

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.