If you would like to inspect one, I just published this watchface yesterday. The math is all @russellcresser for the time zone conversions. You will need to use 3 elements and opacity linked to the VAR for +/-.
3 Likes
Thanks!!!
2 Likes
Hi folks, came across this whilst trying to figure out how to set that up myself. I like some of the approaches here — thanks for sharing! Without having a pro account however ended up doing something slightly simpler, hope someone in future maybe finds this useful. Sorry it’s my first post here on the Facer community, not sure how to ‘embed’ a watch face, but this is the project I was working on —formulas / logic follows underneath:
PVT (Pura Vida Time = Costa Rica Time)
Hour display
((#DUHZ#*1+24-6)%24)
// display
$#DM#>=4&&#DM#<=10?-8:-7$
BRT (Brazil) NB: adapts to DST 
Hour display
$#DM#>=4&&#DM#<=10?((#DUHZ#*1+24+2-5)%24):((#DUHZ#*1+24+1-4)%24)$
// display
$#DM#>=4&&#DM#<=10?-5:-4$
IST (India)
Hour display
$#DUmZ#*1+30>=60?(((#DUHZ#*1+24+5+1)%24)*100+((#DUmZ#*1+30)-60)):(((#DUHZ#*1+24+5)%24)*100+(#DUmZ#*1+30))$
// display
$#DM#>=4&&#DM#<=10?3.5:4.5$
CST (China)
Hour display
((#DUHZ#*1+24+8)%24)
// display
$#DM#>=4&&#DM#<=10?6:7$
If you find any mistakes, let me know! 
2 Likes
Well done . I have not tested it but looking at the Preview I would use a leading Zero if you are going Comando ( without a Colon ) .
Most DLS changes do not change on the last day of the month but what you have is probably the Best that can be done .
2 Likes
Thanks @russellcresser! I don’t know why, though I think it’s a parsing limitation, I can get the DST logic to work (i.e., yield either ‘true’ or ‘false’), but it doesn’t seem to be able to then take the specific functions for either outcome:
$((#DM#>3 && #DM#<10) || (#DM#=3 && (#Dd#-#DOW#)>=25) || (#DM#=10 && (#Dd#-#DOW#)<25))?((#DUHZ#*1+24+2-5)%24):((#DUHZ#*1+24+1-4)%24)$
Do you know where this limitation comes from? Is there a way to mitigate it?
Either way, I guess something I could do manually for now is just reset the DST start / end at day-number level ever year 
I might just do that tbh on this watch face. Hopefully one day Facer integrates this basic sort of thing on their functions … (!) Anyway, for the sake of future readers … here’s the updated version:
PVT (Pura Vida Time = Costa Rica Time)
Hour display
((#DUHZ#*1+24-6)%24)
// display
$#DD#>=89&&#DD#<=299?-8:-7$
BRT (Brazil)
Hour display
$#DD#>=89&&#DD#<=299?((#DUHZ#*1+24+2-5)%24):((#DUHZ#*1+24+1-4)%24)$
// display
$#DD#>=89&&#DD#<=299?-5:-4$
IST (India)
Hour display
$#DUmZ#*1+30>=60?(((#DUHZ#*1+24+5+1)%24)*100+((#DUmZ#*1+30)-60)):(((#DUHZ#*1+24+5)%24)*100+(#DUmZ#*1+30))$
// display
$#DD#>=89&&#DD#<=299?3.5:4.5$
CST (China)
Hour display
((#DUHZ#*1+24+8)%24)
// display
$#DD#>=89&&#DD#<=299?6:7$
And just like before … if you find any mistakes, let me know!
2 Likes
Btw, totally with you, but wanted something even more minimal — less is more 
2 Likes
Yeah . It looks good to me . I don’t understand the *1 unless that is a device to convert variable to integer . I have not extensively tested it but it seems to work . I did not realise India is a half hour zone .
1 Like
Update: wasn’t happy with the limitations, particularly as I wanted to also show PST/PDT and EST/EDT, which only made matters more complicated given CET/CEST ‘centrering’ / perspective. So ended up with effectively ‘three layers’ of the same text components, leveraging opacity function to hide / show things when they’re valid. For these three ‘states’, the opacity formulas should be as follows:
STATE 1
((#DM#<3)||(#DM#>11)||(#DM#==3&&(#Dd#-#DOW#)<8)||(#DM#==11&&(#Dd#-#DOW#)>=1)?100:0)
Definition:
- Neither the US nor Europe is in DST.
- Occurs from:
- Before the second Sunday in March (US has not started DST).
- After the first Sunday in November (US has exited DST).
STATE 2
(((#DM#==3&&(#Dd#-#DOW#)>=8&&(#Dd#-#DOW#)<25)||(#DM#==10&&(#Dd#-#DOW#)>=25))?100:0)
Definition:
- The US is in DST, but Europe is still in Standard Time (CET).
- Occurs in two separate periods:
- Between the second Sunday in March and the last Sunday in March (US starts DST, Europe still in standard time).
- Between the last Sunday in October and the first Sunday in November (Europe exits DST, US still in DST).
STATE 3
(((#DM#>3&&#DM#<10)||(#DM#==3&&(#Dd#-#DOW#)>=25)||(#DM#==10&&(#Dd#-#DOW#)<25))?100:0)
Definition:
- Both the US and Europe are in DST.
- Occurs from:
- The last Sunday in March until the last Sunday in October (US and Europe both in DST).
Also figured out it’s just a simple embedding lol
2 Likes
But… How. I am sure I tested this and it worked a treat
I don’t have the test face but have a message with my results:
((1==1&&1<2)||(1==1&&1==2)||(1==1&&1>2))
true
((1==2&&1<2)||(1==1&&1==2)||(1==1&&1>2))
false
But now it returns nothing in the field I want and my test text field has
$((#Dm#%10%2==0&&#Ds#>0)||(#Dm#%10%2==0&&(#Dsm#-#Ds#)<0.01))?Yay:Nay$
It displays $false?Yay:Nay$
Update:
OK, now this is new, ands astounding to me. You don’t need $ for conditionals unless they are for text output and that has the constraint of the 3 equality tests.
For number output you can do as above as long as your outer are brackets instead of $.
For instance this expression in the YPos only moves an element after the 1st milisecond of second 0:
((#Dm#%10%2==0&&#Ds#>0)||(#Dm#%10%2==0&&#Ds#==0&&(#Dsm#-#Ds#)<0.01)?280:#Dm#%10%2==1&&#Ds#>0?380:#Dm#%10%2==0?(380-(#Dsm#-#Ds#)*100):(280-(#Dsm#-#Ds#)*100))
Why have I not seen this until now? Today is indeed a school day.
This may need its own topic.
3 Likes
I did not know we could do Else If Else If . I wonder what the limit is .
1 Like
Probably the size limit of the expression text, and your troubleshooting sanity. Serial expressions are easier to break down by $$ if you don’t need more than 3 basic equality tests per nest.
1 Like
I used a 100 step serial conditional for romans . But that was not a single conditional .
1 Like