let user decide whether 24:00:00 should be displayed as 00:00:00 of the next day or not

[garrettgman]

R automatically rolls it over, but some users have requested to not have it rollover

[andreas50]

That would be very useful to me as well.

As an example, to me, the "end of 2014" is a date of format "2014-12-31 24:00:00", but not "2015-01-01", which does not even contain the substring "2014".

[vspinu]

What use pattern do you have in mind? @andreas50 can you please provide an example of when this could be useful? I don't follow the context of this issue.

[garrettgman]

Five years later, I'm not sure that this would be correct behavior.

• Is the last moment of Day X really 24:00:00 and not 23:59:59? If a minute is 60 seconds long, it would go from XX:XX:00 to XX:XX:59. If an hour is 60 minutes long, it would go from XX:00:00 to XX:59:59. If a day is 24 hours long, it should go from 00:00:00 to 23:59:59.
• Should one moment simultaneously belong to two days? This would affect set operations and operations that use them.
• Should a 2400 hour exist that is only used for one second? I do not think anyone has asked for 24:00:01 or 28:33:05, etc.

Since this would involve special pleading and an uphill battle against R, the use case should be very important.

[vspinu]

Having this implemented, if possible at all, would require that every accessor, settor and arithmetic operator in the package should know that there exist such a distinction. After all it's the same instant, 24.00.00 is the same as 00.00.00 of the next day, but named differently.

I am closing it for now as non-feasible. Maybe we can address a specific use case that would disallow arithmetics to jump over the boundary, but that's a topic for a different issue.

[andreas50]

As for the implementation, an extra parameter to the print() method could be used to control the display behavior. I agree that it makes no sense to change the application logic of the other methods.

Regarding a use case: I frequently deal with time series data where the observation value pertains to a time period rather than point in time. For example, "the total monthly precipitation in Paris in December 1899". To preserve causality in my analysis, the corresponding observation time has to be exactly at the end of December 1899, which in the lubridate package is printed as "1900-01-01" rather than "1899-12-31 24:00:00". This behavior makes it harder to see which observation value belongs to which time period. (Due to the nature of the analysis, I do not want to represent the data using a monthly time series object such as "ts", because I am mixing and matching multiple time series with different frequencies and many missing values, and because the application logic (such the length of moving averages) is in terms of time intervals rather than number of observations.)

That said, after working with the lubridate package for a few more months, like @garrettgman, I see such behavior as less desirable now, because it would probably be conceptually quite messy and have relatively few users.

[vspinu]

an extra parameter to the print()

If the scope is limited only to printing then it should be doable. But then it's a rather marginal feature I would say.

[andreas50]

I agree. Better to keep it out in this case.