It seems that there’s no supported text for sunrise and sunset times… I thought it might be a leading zero problem, but it seems even tags without a leading zero don’t work. So, I can’t publish a face with these elements.
But also, the sunset time is wrong… the watch face says 19:00, but the weather app says 18:21.
Is this completely broken and shall I give up?
That is correct for WOS6.
You can, however, calculate sunrise/sunset using day of the year and the latitude. Latitude is not supported either, so you would have to hard code it for your location for example.
I’ve been trying to figure it out, but turns out the formulas need the atan function, which only seens to work in Creator but not on my watch. Can do without atan, but the formula is becoming complicated… and not sure when it needs conversion from rad to deg.
Maybe some day …
In any event @djadams the SR SS times given on Facer Creator are for L.A. where the server is . Near Venice Beach actually . But as you have found out , redundant for wfs faces . We are all praying for it to come back one day . So keep playing for practice .
For those interested:
sunrise = 12 − (D/2)
sunset = 12 + (D/2)
whereby D= daylight length
D = 24/pi * acos(-tan(LAT) * tan(δ))
and δ is the Sun’s declination angle
δ = 23.44 * sin(365/360 * DD−81))
23.44 = Earth’s axial tilt
Putting D into Facer notation :
(toFixed(((24/pi)*acos(-tan(deg(#LAT#))*sin(deg(23.44))*sin(2*pi*(#DD#-81)/365))),2))
and without the tan function:
(toFixed(((24/pi)*acos(-(sin(deg(#LAT#))/cos(deg(#LAT#)))*sin(deg(23.44))*sin(2*pi*(#DD#-81)/365))),2))
Thanks for the responses, I’ll find something else to go in the gap 
bro!!!
Here is a test watch with Sunrise and Sunset estimated times that I got my friend Claude to assist with.
Would be good to get some feedback from people in other areas of the world how close the times are for your location.
Here is a pure sinusoidal approximation. Sunrise and sunset follow a smooth seasonal curve that can be modelled directly with sin and cos of the day of year, no acos needed at all.This is a much cleaner solution. No acos, no tan, no complex bracket nesting — just a single cos per formula. Accuracy is within ±14 minutes across the whole year, averaging ±7 minutes. Here are the formulas:
(floor((5.8978+1.3587*(cos(#DD#*0.01721421+0.0859)))))
(floor(((5.8978+1.3587*(cos(#DD#*0.01721421+0.0859)))-floor((5.8978+1.3587*(cos(#DD#*0.01721421+0.0859)))))*60))
(floor((18.1016-1.4150*(cos(#DD#*0.01721421+0.2585)))))
(floor(((18.1016-1.4150*(cos(#DD#*0.01721421+0.2585)))-floor((18.1016-1.4150*(cos(#DD#*0.01721421+0.2585)))))*60))
Key points:
cos and floor
The latitude is baked into the four constants in the formula. To change latitude you just regenerate those constants. Here’s a tool to do it for any latitude:Here’s the table — only 4 values change when you change latitude: A_sr, B_sr, A_ss, B_ss. The phase constants P_sr and P_ss barely change and could even be kept fixed.
The formulas are:
Sunrise Hour: (floor((A_sr + B_sr*(cos(#DD#*0.01721421+P_sr)))))
Sunset Hour: (floor((A_ss + B_ss*(cos(#DD#*0.01721421+P_ss)))))
So for any latitude just swap in the four values from the table:
| Lat | A_sr | B_sr | P_sr | A_ss | B_ss | P_ss | Max error |
|---|---|---|---|---|---|---|---|
| 30° | 5.9157 | 0.9216 | 0.0440 | 18.0838 | -0.9776 | 0.2964 | ±11 min |
| 35° | 5.9077 | 1.1250 | 0.0676 | 18.0917 | -1.1812 | 0.2752 | ±11 min |
| 40° | 5.8978 | 1.3587 | 0.0859 | 18.1016 | -1.4150 | 0.2585 | ±12 min |
| 45° | 5.8852 | 1.6353 | 0.1009 | 18.1142 | -1.6916 | 0.2446 | ±12 min |
| 48° | 5.8758 | 1.8298 | 0.1086 | 18.1237 | -1.8861 | 0.2373 | ±13 min |
| 51° | 5.8644 | 2.0535 | 0.1158 | 18.1351 | -2.1099 | 0.2306 | ±14 min |
| 53° | 5.8553 | 2.2235 | 0.1202 | 18.1441 | -2.2799 | 0.2264 | ±14 min |
| 55° | 5.8447 | 2.4149 | 0.1245 | 18.1547 | -2.4713 | 0.2223 | ±15 min |
| 60° | 5.8070 | 3.0312 | 0.1346 | 18.1925 | -3.0877 | 0.2127 | ±18 min |
Just tell me your target latitude and I’ll output the ready-to-paste formulas with those values substituted in. (Thats Claude… not me!)
While it looks promising, I have a question.
Is there some way how to go around the longitude?
I mean the #DOFST# tag provides minutes ofset for the actual time zone, but not for local solar time.
Some time zones are broad, spreading from west to east zone border like over 3 hour stripes.
For example in Spain and France are places with sun rising in same moment as in England, yet they are one hour ahead with local time. Even in regular 15° timezone stripe is one half hour error granted, since the time zone ofset matches solar time only on its central meridian.
Its not perfect… but the formula is also not over complicated. Given the +/- max error averaging 7 minutes, I think it is a good temporary workaround until Google do the decent thing and provide an official WFF tag. But I am sure there may be others here that can further perfect the formula.
However, once that is perfected, then you have the issue of replicating #DISDAYTIME#
Here’s the opacity formula. The logic is: convert current time and both thresholds to total minutes, then compare.Boundaries are clean. Here is the opacity formula:
$(#DH#*60+#Dm#)>=((5.8978+1.3587*(cos(#DD#*0.01721421+0.0859)))*60)&&(#DH#*60+#Dm#)<((18.1016-1.4150*(cos(#DD#*0.01721421+0.2585)))*60)?100:0$
How it works — everything is converted to minutes from midnight to avoid any floating point hour/minute split issues:
#DH#*60+#Dm# — current time in minutessunrise_decimal * 60 — sunrise threshold in minutessunset_decimal * 60 — sunset threshold in minutesThe nested ternary reads as: if current >= sunrise, then (if current < sunset then 100 else 0) else 0.
Verified boundaries for today GMT:
0 (night)100 (day, just after sunrise)100 (day, just before sunset)0 (night)It did cross my mind if it were possible to have a generic formula just using day of the year (DD), but as you can imagine the error is rather large. With the help of AI (you can have ChatGPT reverse engineer it if you want to know how it was derived…):
daylight ≈ 12 + 3.7 * sin(2*pi*(DD - 80)/365)
error: 10-30 minutes, which is not bad, but it assumes a global latitude average of 45°
The further away you are from the 45° the error will be as large as 1-2 hours.
Optimal latitude. The answer isn’t just “pick the middle latitude” — it depends on where smartwatch users actually are.
The data tells a clear story. Here’s the honest summary:
The B constant (amplitude) is directly driven by latitude. A user in Stockholm has ~5 hours of seasonal swing; a user in Singapore has ~20 minutes. No single baked-in latitude can represent both.
| Actual location | Model lat=35° | Model lat=40° | Model lat=45° |
|---|---|---|---|
| Equator (0°) | 73 min | 88 min | 105 min |
| India/SE Asia (20°) | 39 min | 53 min | 69 min |
| US South / China (30°) | 21 min | 33 min | 49 min |
| Tokyo / LA (35°) | 11 min | 22 min | 37 min |
| NYC / Madrid (40°) | 21 min | 12 min | 25 min |
| UK / Paris (45-50°) | 37-58 min | 24-44 min | 12-28 min |
| Stockholm (60°) | 131 min | 116 min | 99 min |
Use lat=40° as the global default. It sits at the sweet spot of the error curve, minimising errors for the highest-density smartwatch markets — US, Europe, China, Japan, Korea — all of which cluster between 30-55°N. It never exceeds ~116 min even at the extremes, and stays under 45 min for roughly 80% of the world’s smartwatch users.
For the opacity formula specifically the errors matter less than for displaying the actual time — being 30 minutes wrong at the day/night boundary is barely noticeable in practice.
But for a general-purpose watch face, lat=40 is the most defensible single choice.
I think while 0° meridian runs trough London and is close enough for whole UK, if you are located in Paris, you may be only 2.3° eastwards (which should mean 9 min difference), but the actual error will be like 51 min due your position 12.7° westwards from your time zone meridian (without even counting in the error from latitude).
How do we petition google for a sunrise/sunset tag?
How far out are the sunrise sunset times when synced to your watch? I don’t know which part of the world you are located.
40° Latitude - Worst case for users near lat=40 is around ±12 minutes.
Sunrise/sunset times are approximate and optimised for mid-latitudes (30–50°N/S)".
I’ll test it tonight. I am at 47.3769°
I am at about 48°N and 17°E, in CET (+1:00)
That gives solar time 8min ahead of time zone
#WSUNRISE# = 5:45 #WSUNSET24# = 18:10
Your formula returns sunrise 6:57 sunset 19:17
I dont know where the extra hour is comming from.
Try again now. The issue is with the #DOFST# tag. I have made an adjustment and it is working for UK and CET time.
Yes, it is 1h better now 
Ive removed the DOFST from the formulas. It was causing errors and not needed. CET is +1 hour currently so 60mins is correct. 29th March uk switch to BST -1 hour
Yes, silly me! 60 was correct all along. Not sure what Creator uses…
