Time - documentation and consistency in the code

[suegrimmond]

Problem

1. need to be explicit in the documentation/Manual what time is being used
2. Time is relevant to meteorological forcing and to profiles
3. Times change in many places - with DST (daylight savings time) going on/off - so the alignment of profiles and meteorology will change.
4. UTC is generally used in the meteorology world
5. ST - standard time (e.g. EST - eastern standard time) is more useful for local applications
6. Proposal -(a) all calculations done in UTC (b) profiles in the region's ST (c) output in UTC and option for region S or ST and DT (Daylight time). (d) codes deals with summer/winter time
7. Internally - times all dealt with in one place - no corrections done elsewhere - and the alignment of profiles done using a consistent method throughout.
8. Changes this implies (a) calculations done in UTC (b) assumption of ALL profiles region ST (c) remove some unnecessary checks -(d) provide option for different time outputs (e) make documentation clear (Time section and link to all inputs that have a time component have a link explaining assumption
9. Day of Week and hemisphere checks also needed

[sunt05]

Thanks @suegrimmond for the clear points – on this issue now.

[sunt05]

Thanks @suegrimmond. Most of the detail is internal engineering I can take forward; two user-facing convention choices need the group's call first. @denisehertwig @MatthewPaskin

1. Forcing-file clock. Make the convention explicit (standard or utc), defaulting to local Standard Time now so existing forcing files are unaffected, and move to UTC as the default in a future release. Agree?

2. Output clock. Your proposal was output in UTC by default. I'd suggest output instead follows the input clock by default (so no one's existing output silently shifts), with a one-line option to emit UTC, Standard, or Daylight time. Same capability, no surprise. Happy with that, or would you rather UTC be the hard default?

Everything else (centralising the time logic, treating profiles as Standard Time, how daylight saving is applied internally) I'll take as engineering decisions and lay out in the implementation sub-issues.