That’s the ‘presentation’ formula, and includes ‘leading zero’ logic.
You want something like:
((((#DUHZ#+2)/12)+(#DUmZ#/720))*360)
And substituting (for ‘+2’), I suggest:
(((((#DUHZ#+#VAR_1#)/12)+(#DUmZ#/720))*360)%360)
1 Like
This looks nice but it´s working in the wrong direction.
But when i choose - instead of + it doesn´t work with -1, -2 …
(((((#DUHZ#-#VAR_1#)/12)+(#DUmZ#/720))*360)%360)
1 Like
Try this:
(((((#DUHZ#+(#VAR_1#*-1))/12)+(#DUmZ#/720))*360)%360)
1 Like
That´s it! Nice! You´re my superhero of the day!!
That´s what it looks like now. Press left or right on the WT-bevel, Above for reset to UTC 0.
2 Likes
You may also need wrap-around logic, as your +/- variable is open-ended.
I suggest this:
(((((#DUHZ#+((#VAR_1#%12)*-1))/12)+(#DUmZ#/720))*360)%360)
1 Like
True! Thank you very much for your help. Now i know that it is 8 pm in Sydney. 
Mission World timer accomplished.
I will mention you when the final watch face is ready.
@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.
Thanks,
John
1 Like
Can you confirm if ‘World Clocks v0.2’ (above) is correct for NYC (!?).
Note: It is set to Summer Time (EDT), and as yet has no logic for EST …
@jmorga106, OR @GAUSS,
What value is VAR_1 when ‘correct’ (on ‘World Timer test’) for NYC?
Note: I still don’t have access to new ‘Premium Designer’ #VAR# toys (or documentation), so was just (wildly) guessing.
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)
-john
1 Like
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??? 
2 Likes
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’ll finish this watch someday lol,
-john
2 Likes
It is complicated with a load of variables.
That‘s why i only made a rotating bezel and hand depending on utc.
1 Like
So, would you be in favour of a ‘black box’, embedded in Facer, that did most of this for you?
1 Like
Surrrre if it’s not too much trouble. but I gotta figure this out. I’m close…
1 Like
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 …
2 Likes
Hi Andrew, did you end up publishing your day and date solution for UTC? I can’t seem to find another person who was close.
I have made progress for UTC, and am still working on timezones (but making some progress).
Current thread: Select Timezone feature
Which showed this:
4 Likes
Thanks Andrew
I’ve started a thread of my own, relating to my specific goal.
1 Like
Wouldn’t it be nice to have an expression such as dateTimeByZone(hour24,GMT), dateTimeByZone(dayNameShort,EST)
1 Like