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.
I tortured myself with the same formulae issues … before I just switch to using #DNOW#.
Once I had formulaic logic to return Year, Month, Day and Hours, Minutes from #DNOW#, it is easy to just adjust the time by +/- 1-13 hours. Then you just have to deal with Daylight/Summer Time start/end dates, etc.
My problem is that gets too complicated and has to be repeated 20-30 times in a single watchface …