You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 13, 2022. It is now read-only.
We need to either alert the user to look for and change that 0:00 to 24:00 before loading their data, or find a way to discover if it is coming in that way and fix it for the user.
The text was updated successfully, but these errors were encountered:
It doesn't matter unless there was rain during that minute. So sometimes the files with that format work fine. When there is rain during that minute, even just once in a huge file, RMevents craps out and makes the end time earlier than the start time.
@rbcarvin -- do you think an acceptable solution would be to look for zeros in the time component, and if so, convert it to the normal way? Or if it occurs throw a warning instead of continuing to compute?
I'm testing to see if the 2015 05 14 0:00 timestamp needs to be 2015 05 14 24:00 OR 2015 05 15 0:00 Or if it could be either. It seems most data sets put that minute into the next day (2015 05 15 0:00) instead of the previous day. But maybe it doesn't matter.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Some raw files write the last minute of the day as: 0:00 instead of 24:00. This appears to be the way data were output in BCards from ADAPS.
For example:
2015 05 14 23:59
2015 05 14 0:00
2015 05 15 0:01
We need to either alert the user to look for and change that 0:00 to 24:00 before loading their data, or find a way to discover if it is coming in that way and fix it for the user.
The text was updated successfully, but these errors were encountered: