Currently there are 13 tags for UTC date/time. Nine are for hour, and two each for minutes and seconds.
There are no equivalent tags for some forms, and none for UTC Year, Month or Day (of month, or year). This has some unintended consequences, and is difficult (if not impossible) to rectify with conditional logic.
The minimum requirement is 2 new tags:
#DUd# - which would provide the correct day-in-year and day-in-month UTC values for date calculations.
And 2 new tags (?
#diffDm#) for hour- and minute-difference to support timezone calculations.
ie. for PDT (US, Pacific Daylight): -7 hours, -0 minutes
ie. for AEST (Australia, Eastern Standard): +10 hours, +0 minutes
Note: Using an expression like
$#DH#-#DUH#<0? (#DD#-1) : #DD# $ is problematic for all possible local timezones.
Additional: (further to Solution 1)
A more elegant solution would be support for 'pragma' prefixes (eg.
&timezone:UTC& (or short form:
&tz:UTC&), and then removing all the existing (presentation) UTC specific tags. The root tags (
#DUs#) are still needed for calculations.
Also useful would be:
&timezone:daylight& to force daylight time, and
&timezone:standard& to force standard time. This is needed for displaying both or complex fields/dials that are calculated during/over the daylight/standard transition.
This could be extend to forcing PST (or PDT), or other timezones - for showing dual timezones or many timezones.
Non-displaying formulae fields, with user variables for using the output in their watchface design (or as input to other formulae).
This is NOT specific to date/time, and would still need additional timezone and UTC tags or functions.
Design discussed here: http://community.facer.io/t/forumlae-only-page-alongside-current-wysiwyg-view/24274
This would allow easy sharing and re-use of favourite formulae (moon-phase, animation, etc.), with the ability to change, swap, or update the code without needing to edit the display portion of the watchface.
Solution 3: (Recommended)
A 'black box' software engine, embedded in Facer (Creator, and on watch runtime)
Initial dates, timezones, or numbers (from more complex calculations: Easter, Islamic Calendar, regional holidays, etc. ) are loaded (using a new set of functions).
You crank the handle, or adjust the time/date by a number of hours, days, or months .. and then the results return as tags for controls of dials/hands or time/date numeric fields.
This would provide full support for ALL timezones, locale preferences (AM/PM, 24HR, dd-mm, MM/DD, etc.), astronomical calculations, and workout calendars .. all without making the expressions for watch layout too complex.