Store start and end timestamps instead of "days" duration

[mstenta]

Currently the {farm_grazing_rotations} table stores a "start_time" (timestamp, as an integer) and a "duration" (number of days, as a float).

I think we should drop the "duration" and replace it with an "end_time" field, which stores the rotation's end timestamp. And then in the UI, wherever the "grazing days" (duration) is displayed, back calculate it by subtracting the timestamps and dividing by 86400 (1 day). So in other words: the "grazing days" would be simply a front-end representation (rounded), but not stored in the database.

When we store "duration" in days, it is always being rounded to a specific precision (I think 2 decimal places in all instances). This rounding can cause issues. For example: if a user manually sets the timestamp of a log (ie: by rescheduling it), the timestamp that they choose may not fit perfectly into a duration - so if/when that rotation get's recalculated it will go off of the duration, and overwrite the "actual" timestamp that was entered by the user. In most cases this isn't a big issue, because the difference will be small - but it is not precise, and may add up to large issues/discrepancies.

This is related to (and may be part of the solution for):
#4
#27

[mstenta]

Another possibility (from Steve): instead of storing an end time as a timestamp, store the duration in seconds (instead of days).

[mstenta]

Another another possibility: leave it as "days" duration, but don't round it before storing it. Only round before displaying it.

[woodbri]

duration in days is store as a float, so multiply it 84600 to get seconds.