I’m my testing, it does not work on my watch the day after I made it in creator.

1 Like

I have been using $#DISDAYTIME#==true?100:0$ and $#DISDAYTIME#==false?100:0$ on my personal watch faces that are unpublished and only I wear. I never have problems with it except not changing until the information update in Facer which is usually fairly close. But it keeps on working day after day. The Facer creator only works with it on the current day, and I use 8:00 am & pm to check its function. I would recommend to prevent issues, use the double equal sign (==) and not the single one. Double equal signs are just a good practice to avoid issues in any expression used in Facer.

1 Like

@michaelavascarlet197 Stand by. #DISDAYTIME# does not work on all watches. I think it is Tick Watch that does not like it. When I get on my Laptop I will post here a Grunt Formula that is actually more robust but a bit longer. :joy:. Sorry I might Forget. I have that problem these days. You could offer a cautious reminder if I have not got back in a couple of hours. :+1::wink:

Please try this for Opacity . 100% during Day Light


Have Fun . :sun_with_face: :waning_crescent_moon: :+1:

Be careful with that one, those short sunrise/sunset tags do not work on all watches either :wink:

1 Like

@ThaMattie @kvansant . I have played a lot with SR SS DISDAYTIME and the Formula Above . One of or problems is there are a few Sun Rise and Sun Sets Civil , Aeronautical and the Like . The times reported by Open Weather are within 1 or 2 minutes of other data I can pull from the Net . It is the classic where the Sun is Half clipped by the Horizon . I live very near the sea so see these things well in the Spring and Autumn being in the UK . I think one of the problems is Open Weather Data updating to the Watch . There is nothing any of us can do about that . I find that if I am not continually syncing other stuff and just Leave MY Day Watch running on its own for a few Hours everything is updated as well as I would expect . Weather , LAT LNG , DNOW , Time Zone (AOD only ) ,
I personally feel if this one can be kept On Topic it will be very useful . The Author Has given it a Good Title . Got My Attention .


@ThaMattie . That formula if that is what you mean is a long one for me . Is there something more robust then that will work across all watches ?

Having had two (cheap) TicWatches that I used for testing. (One was a TicWatch E first gen and the other was a TicWatch S2, both of them dropped dead before being 6 months old) I discovered they work fine with #DISDAYTIME# but only if you use true/false. If you use 0/1 only Samsung Tizen will display it correctly. My question is, where would you use #DISDAYTIME# other than the day or night filter?


@russellcresser I’m taking about the tags. Looking at Facer documentations, these are what I refer to as the “short” tags for sunrise/set:

#WRh# Sunrise hour (1-12) 5 All
#WRhZ# Sunrise hour (leading zero) (01-12) 5 All
#WRH# Sunrise hour (0-23) 5 All
#WRHZ# Sunrise hour (leading zero) (00-23) 5 All
#WRm# Sunrise minute (0-59) 50 All
#WRmZ# Sunrise minute (leading zero) (00-59) 6 All
#WSh# Sunset hour (1-12) 8 All
#WShZ# Sunset hour (leading zero) (01-12) 8 All
#WSH# Sunset hour (0-23) 20 All
#WSHZ# Sunset hour (leading zero) (00-23) 1 All
#WSm# Sunset minute (0-59) 6 All
#WSmZ# Sunset minute (leading zero) (00-59) 6 All

End deze would be the “long” ones:

#WSUNRISE# Time of sunrise 5:50 AM All
#WSUNSET# Time of sunset 8:06 PM All
#WSUNRISE24# Time of sunrise (24) 5:50 All
#WSUNSET24# Time of sunset (24) 20:06 All
#WSUNRISEH# Hour of sunrise 5 All
#WSUNRISEM# Minute of sunrise 50 All
#WSUNSETH# Hour of sunset 8 All
#WSUNSETM# Minute of sunset 6 All
#WSUNRISEH24# Hour of sunrise (24) 5 All
#WSUNSETH24# Hour of sunset (24) 20 All

On my watch the “short” ones are blank, but the long ones work.
They have similar information, and you can achieve the same you are doing with the long tags too.


@ThaMattie . Now I remember seeing your work on this . So use the long Tags yeah .Cool . So much to Learn . Thanks for the heads up . I will make a Test .


@michaelavascarlet197 @ThaMattie If in Doubt Go for the Long Grunt . The Cheat is just a Maths joke but Hey HO . We are suppose to be having Fun . Thanks to Mattie who has been there for lots of People on Facer at Many Different Levels.

1 Like

Here’s an issue that you won’t know about unless you have more than one watch to test with. On sunrise & sunset tags, they force an am/pm display after the time. On sunrise24 & sunset24 they display correctly on WearOS, but on Tizen sunrise24 drops the leading zero on sunrise. Using wsunriseh & wsunseth forces a leading zero on WearOS with 12-hour preference but doesn’t with Tizen.

I have received complaints on all of these issues in the past. On the am/pm issue I get “I know the sun rises in the morning” type of complaints. On 12-hour preference I get a lot of “remove the zero” complaints. On 24-hour preference I get questioned about where the leading zero is at. (Tizen users only)

It seems to me that no matter what sun rise/set tag you use someone is going to complain about it.


Thanks MAG . I always thought that was what the 24hrs Clock was for . The Bus time tables for the Old Ladies down here are 24hrs no AM PM they seem to be there on time to get the Bus. Thanks for he heads up . Fortunately we are just switching stuff on and off at the moment. Good on Topic Stuff . As always when the Usual Suspects get involved The Topic becomes worth Bookmarking .


Yeah, I can imagine. I do not have any face (yet) that displays the actual times, but I use them in expressions to make graphical representations of day and night. Those always use the seperate hour and minute tags and the leading zero doesn’t matter there.

This could be solved in WearOS by adding parentheses. Anything in parentheses becomes a number, and numbers don’t display leading zero’s. For 24h you could then add the leading zero in the expression and it would work for both.

In fact, that will also work with “booleans”:
#DISDAYTIME#==true is the same as (#DISDAYTIME#)==1 (And I’ve actually used it without conditions by setting opacity to (#DISDAYTIME#)*100


Ha Ha I have ((#DISDAYTIME#)*100) in my test . Unfortunately I thought I discovered it . :::)))


Just tested this out:
Sunrise 12h


Sunrise 24h


Sunset 12h


Sunset 24h


They all displayed exactly correct for no leading zero on 12-hour and leading zeros on 24-hour selection on both my WearOS and Tizen watches. This is how I will be doing sunrise and sunset times from now on! One Big Thank You @ThaMattie !


Wow, another query post that has turned advanced tutorial. So much useful information here it needed to be bookmarked.

I just hope it isn’t information overload for @michaelavascarlet197 in his early days. There has certainly been a lot of grunting going on and thanks to all for the information and efforts involved in this.

1 Like

You are assuming the sun will always rise before 10am with this though :wink: In the reaaaaally nordic regions, it will end up as 010:29 like this. The 0 would need a <=9 check. Don’t know if there are sunsets before 10am, otherwise the sunset24 also needs a conditional leading zero.


That thought had crossed my mind. On the other hand, just how many people in those remote areas are going to care about the sunrise? Just for grins and giggles I checked online for today’s sunrise and sunset times in Qaanaaq Greenland. The website said, “Down all day”. Sounds like they need to know the sunrise and sunset weeks instead of hours and minutes. :laughing:



Thank everyone so much! I have learned so much. Creator is taking up all of my time in a good way!


UPDATE the color finally changed 7 hours after sunrise so it is making me think it might be something to do with a weather updating feature?

1 Like