Discussion about the ZBasic language including the System Library. If you're not sure where to post your message, do it here. However, do not make test posts here; that's the purpose of the Sandbox.
'test date
dim inYY as integer,byMonth as byte,byDay as byte
Call GetDate(inYY,byMonth,byDay)
debug.print byday;"/";byMonth;"/";inYY
'Check to see if we can rest tubes
byDOW=GetDayofWeek()
debug.print "DOW=";byDow
FFMan wrote:I must be doing something wrong, day of week for today returns as 7 when it's a friday.
No, it's a heretofore undiscovered bug in GetDayOfWeek().
There is an updated version of the ZBasic Library, v4.3.5, that corrects the problem. You can download just that part or get a whole new installer that contains that update plus an update to the compiler.
I created a test program (attached) that iterates through all of the day numbers from 0 to &Hffff and calculates the DayOfWeek for each, comparing the result to the expected. No discrepancies are reported here when I build and run that app. Please try this on your end and report the result. If that works as expected then it is probably an issue with conversion between month/day/year and day number.
If the updated test program produces the correct result, I would encourage you to create a simple test program that demonstrates the problem that you observed. That way I can home in on the the underlying issue.
i'm still working through this but i can see why i get the discrepancy, it's due to the date being set for a different year, so the DOW is different.
The code in esp8266 client udp NTP example adjusts the epoch bu deducting 3629059200
Code i took from another example from zbasic.net contained this code and comment:-
Private Const DeltaZBasicNTP as UnsignedLong = 3124137600 ' seconds btw 1900/1/1 and 1999/1/1
I need to delve into this a bit more, but is it possible the offset used in the clientudp example is incorrect maybe as it only debug.print the time, whereas the other example I know sets the date correctly.
FFMan wrote:is it possible the offset used in the clientudp example is incorrect maybe as it only debug.print the time, whereas the other example I know sets the date correctly.
Notwithstanding the comment in the UDP code, the 3,629,059,200 second adjustment shifts the year to 2015 (which was, not coincidentally I suspect, when the code was written).
The correct seconds offset between 01 Jan 1900 and 01 Jan 1999 is 3,124,137,600 (i.e. 36,159 days).