@iDoug wrote:
Every coder is going to understand that “water time” is different from “time” or “datetime”?
Every coder is going to know how to convert “water time” to/from “time” or “datetime”, and be able to do the math?
First of all, using datetime (timestamp) makes no sense for a duration field. I am not sure what you mean about converting a duration to datetime.
Are you suggesting we give users a start date and end date for each station?
The proposed solution depends on people understanding the value so answering your question, yes, they cannot just use it assuming it represents a value such as seconds.
@iDoug wrote:
No user will ever want more than 63 units?
The point of this thread is to weed out what user’s need in terms of water time.
@iDoug wrote:
I am still of the belief, if the function for storing the time accepted a standard time data type, none of this would be an issue.
Although I understand what you are saying here this is deceiving to the end user. If we just accept and send a duration value from the UI side without trying to understand what the firmware is doing then you will run into situations where the user’s set value is not valid, such as 1 hour and 30 minutes (since the controller is rounding to the highest selected unit).
Also, the idea is to save space not use more. We are discussing fitting the watering time per station to one byte to allow more programs on the controller, especially for a user with many stations.