#DW# is week of month. The first day of Week 1 is the 1st of the month, regardless of what day of the week it falls on.
Here is the odd result: The first day of Week 2 is the 7th of the month. You would expect the 7th to still be in week 1, but Week 1 only has 6 days, according to Creator. I have not tried this on a watch, because you can’t arbitrarily change the date to test different dates.
well with this information… my assumption is the first day would be day 0 then?
Computers generally start counting at Zero. Alot of applications hide this at the user level. But at the programmer level you have to account for it. First records are usually 0. Next is 1… then 2… on an on. Working with arrays on PLCs alot of the time we leave 0 unused if we are working in a linear numbers series of devices. Line Motors 1-10…You set your array to have 11 elements then simply ignore 0’s existence. its mentally easier to use 1-10 rather than 0-9. So each motor can mentally be matched to its array number. While reworking some code i had to write a cheat sheet and hang it on my monitor to help me remember which array items were how much higher or lower than their device number. 3 separate components… one was 7 higher (One-Shots) , one matched, another was 1 lower(someone started at zero). We fixed the 1 lower by bumping everything up by one. Made it easier. the 7 higher, not much we could do there without judicious recoding. Not worth the time.
Roger_Wilco, thank for you for response. I have a BS in Computer Science and have been in the software development industry for 38 years, so I am well-versed in what you are describing. C programmers love this. But it doesn’t explain this quirk.
Months do not start on day 0, they start on day 1. The last day of the previous month is shown as #DW# = 4 or 5 for that month, never treated as day 0 to return #DW# = 1 for the following month. Days 1-6 are considered week 1. That’s only 6 days. Days 7-13 are considered week 2, and that is 7 days. Days 14-20 is week 3, and that is also 7 days. Days 21-27 is week 3, 7 days.
Since I posted this I discovered #DF#, which is week of month with the expected value of 1 for days 1-7.
I cannot imagine the intended purpose of #DW# when #DF# is available.
Assume that Week 1 starts on Saturday, week 1 only has 1 day. the second day of the month and the 7th then fall into week 2. DW is just Week of Month so it will only vary between 1 and 5. As said when you consider the Array yes months DO start on day Zero in the computer. I’d hope facer would employ the same obfuscation tactic and simply make the 1st the second element of the array, abandoning the first element (0)
DW and DF both seem broken looking at them.
Using April 2018 as an example since APril 1 is a sunday…
I would make the assumption that DF (Day of Week in Month) would make sunday Day 1, which it does, and Monday Day 2… which is does NOT.
DW advances on Saturday. So I wonder if its working Sat-Fri instead of Sun-Sat OR of this is an effect of a earlier noticed DST issue.
I just tested after remember what I found with another user having him back his date up before DST change, its caused by a DST intepretation error. I backed up to Feb. DW advanced as expected. Its the one hour DST change that messes things up.
DF which is supposed to be Day of Week which should advance daily from 1-7(Until end of Sat or End of Month). Advances WEEKLY 1-5.
@Facer_Official add another bit of evidence to the earlier noticed DST handling fault. Also DF needs to be looked at as it doesn’t function within what its description suggests.
It appears that Facer does not assume this. It appears that “week of month” is not the calendar week, but rather the 7-day period. I gave specific examples upthread to describe how this works. For #DF#, the 1st of the month is always the first day of week 1 of that month, no matter what day of the week it falls on. The 9th of the month is always the second day of the week 2.
Sadly the documentation says only “Day of week in month” which is kind of vague. It looks like you are right; this is intended to be 1-7 showing the position of the day relative to the week returned by #DW#. Instead it seems to show the week number.
So both of these tags seems to have errors.
DW works properly when you jump back to FEB.Its caused by the one hour offset. Facer handles DST about like a 16 year old handles Booze. BADLY!
DF is just totally borked. If Wednesday was the first day of the week in a new month it Should return 1. Thurs 2. Sat 4. Sun would reset to 1. DF acts like DW SHOULD act.
Create a new watch and Add two text elements in the text field add these
DW #DW# Week in Month
DF #DF# Day of Week in Month
(Done so its easy to see whats what, and what they are claimed to be by text descriptor.)
Now go to Feb 2018 and jump from Sat to Sat, watch them BOTH advance like DW should.
Now Go to April 2018. Sat to Sat… DF acts like DW should. DW being delayed by one hour is goofed up. It it seems to have a similar effect. Previously working with another designer on an issue he had I found out that Facer doesn’t handle DST changes properly. I’m not sure what facer reads to determine time/date. but it acts like they read the phones time for the clock and then internet time for the date which doesn’t change. Its up to the device to apply DST calculations to it. Advancing from Sunday to Monday at 1am would but unnoticed by most people because they will be asleep, so it would’nt affect many. It seems to have a larger noticeable affect against #DW# throughout the day.