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.
Solution 1:
The minimum requirement is 2 new tags: #DUD# and #DUd# - which would provide the correct day-in-year and day-in-month UTC values for date calculations.
And 2 new tags (? #diffDH# and #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 (#DUH#, #DUm#, and #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.
Solution 2:
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.
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.
While it does give the correct value, adding Daylight / Summer Time and leading zero-logic may get close to the size limit for expression size (already hit a few times, doing the trig2 version of moon phase). Each additional layer of logic usually involves repeated repetition of the root expression (as you already see here).
Six clock faces, all in different timezones, including UTC and local (whenever that is).
This fully supports leap-year, end-of-month, and end-of-year conditions. I have yet to add Daylight / Summer Time and associated calendar logic (which I will test elsewhere first).
I just modificated your text base formula into rotation by adding rotation angle. That does the trick but it only works for 12h, the other 12h the hand stays on the 12 o´clock position.
What i need is a UTC based rotating hour hand that can be modified with #VAR# decrement and increment (-1/+1), choosing the timezone, beginning at GMT/UTC.
Formula for #VAR#-rotation in angle steps could be made by: * (#VAR_1# * -15).
@andrew.dowden, @GAUSS,
For sure this is tremendous math work well done! but I think you’re short one hour. Can you check on #DUHZ#?
I live in New York so as a quick litmus test I have my local time on the watch above and set the outer ring also to New York. The times should be identical but the zone 2 time is short one hour.
I just dropped an extra 1 on DUHZ to catch up… works through midnight on all zones. ((((((#DUHZ#+1)+((#VAR_1#%12)*-1))/12)+(#DUmZ#/720))*360)%360)
Can you verify? I’m using the edited formula above in a new watch.
that’s some pretty awesome guessing dude… Yes the daylight savings tracks correctly. Is it BST in UK? I know there’s a few week where they probably don’t match but by July they should track (London is +5)
Wow this is getting really complicated. What if you wanted to also display the digital time as well - locally and in zone 2?
…aaaaaaaaaaand pad the leading zero(0) on 24-hour time?
…aaaaaaaaaaand what if the users can switch between 12 and 24 hour format?
I’m padding the lead zero(0) on 24-hour time like this: $#Db#<10||#Db#>=24?(0)#DK#:#Db#$
Premium designers must use the #Db# tag for hours on all designs to publish. Otherwise, Facer QA kicks them back.
The trick will be to modulus %12 on 12 hour time or modulus %24 on 24 hour time depending on user format. But there’s
no tag for that.
Still messing with some condition if #Db# goes over 12, then change the Modulus value, then add the #VAR_3# plus 1 to get to the ZONE 2 time. So if it is 10:14am in NY it should either be 3:14pm in London or 15:14 in London based on the user’s setting. How do I get myself wrapped up in these things???
Gawwwwwwwwwwwwwwwd… my brain hurts and it’s too complicated. I just did it with layers.
Scratch the below - my hours are moving in the wrong direction
scratch - So, ZONE2 hours is: (#DUHZ#+#VAR_3#+1)
scratch - but is only visible when hours are less than 24: $(#DUHZ#+#VAR_3#+1)<24?100:0$
scratch - the one case when the offset = 24 I’m showing double zeroes (00) as a separate text layer
scratch - shows when: $(#DUHZ#+#VAR_3#+1)=24?100:0$
scratch - the cases less than 10, I’m padding a spare zero (0) in front of the single hour number with another text layer:
scratch - shows when: $(#DUHZ#+#VAR_3#+1)<10?100:0$
I’LL FIGURE THIS OUT EVENTUALLY…
and then of course the minutes are just the regular #DmZ#
The hours and the extra zero layers are all left-justified.
The minutes (with colon : in front) is right-justified.
It’s all oriented so the colon : lands center-line.
I didn’t bother with 12-hour time for international zones. But the local time uses #Db# on hours.
