Possible wrong definition of DayOfYear() and DayOfWeek() in the documentation?

New comment
 

In the documentation:

int DayOfWeek(  	)
Returns the current zero-based day of the week (0-Sunday,1,2,3,4,5,6) of the last known server time.
int DayOfYear(  	)
Returns the current day of the year (1 means 1 January,..,365(6) does 31 December), i.e., the day of year of the last known server time.


From my testing they both return the days of the last known server time at the moment of program start (similiar to Minute(), Hour() functions) and NOT as stated in the documentation.


To prove this I run a simple expert:

int init()
  {
//----
   start();
//----
   return(0);
  }

int start()
  {
//----
   while(true)
      {
      Print("TimeCurrent() = " + TimeToStr(TimeCurrent(),TIME_SECONDS) 
          + ", DayOfYear() = " + DayOfYear() 
          + ", TimeDayOfYear(TimeCurrent()) = " + TimeDayOfYear(TimeCurrent()) );
      Print("TimeCurrent() = " + TimeToStr(TimeCurrent(),TIME_SECONDS) 
          + ", DayOfWeek() = " + DayOfWeek() 
          + ", TimeDayOfWeek(TimeCurrent()) = " + TimeDayOfWeek(TimeCurrent()) );
      
      Sleep(60*1000);
      }
//----
   return(0);
  }


I run it through the night. Here is the log output before and after midnight:

05:58:41 test EURCHF,H4: TimeCurrent() = 23:59:48, DayOfYear() = 348, TimeDayOfYear(TimeCurrent()) = 348
05:58:41 test EURCHF,H4: TimeCurrent() = 23:59:48, DayOfWeek() = 1, TimeDayOfWeek(TimeCurrent()) = 1
05:59:47 test EURCHF,H4: TimeCurrent() = 00:00:53, DayOfYear() = 348, TimeDayOfYear(TimeCurrent()) = 349
05:59:47 test EURCHF,H4: TimeCurrent() = 00:00:53, DayOfWeek() = 1, TimeDayOfWeek(TimeCurrent()) = 2


So my theory is that the definition in the documentation is wrong and DayOfWeek(), DayOfYear() return the days at the last known server time AT THE MOMENT OF PROGRAM START. Can anybody please confirm this? Or if I am wrong then please explain why this expert gives this output?

 

perl, php and mq4 have bugs.

you have to workaround this bugs.

storing a result of your mentioned functions in another variable and use the variable in further calculations may be one solution.

because its a bug, there is no general solution.

i have had problems with Days() and fixed it in the mentioned way.

make your own test and bugfixes.

and remember, perl is one of the largest languages avaiable and has bugs, though mq4 is allowed to have some bugs too.

 

If this bug consistently returns the days at last known server time at the moment of program start, then all MQ needs to do is fix the documentation and this will no longer be a bug.


The question is - is this function consistent in it's return or not? If so, then MQ has to fix the documentation...

 

with my experience til now i can use all mq4 functions with the documented results, but sometimes with a workaround depending on the special situation.

i have 30 years experience in programming in different languages, and such things are happening from time to time in every language.

the only solution can be made by the programmers, and those are you and me.

dont blame others for bugs.

if you want to, write your own compiler

 
As I said, this does NOT seem to be a bug, just a wrong definition in the manual. All my tests so far have shown consistent results for these functions. So I have seen no bug. But the results do not fit the definition in the manual...
 
You are in a loop without refreshing, either add a refresh or exit start
 
You don't need to refresh to get the new latest server time. If that was true then TimeCurrent() would have given the same result with no refresh, but it does not! RefreshRates() is only relevant to Predefined variables (https://docs.mql4.com/predefined/variables)
 
gordon:
You don't need to refresh to get the new latest server time. If that was true then TimeCurrent() would have given the same result with no refresh, but it does not! RefreshRates() is only relevant to Predefined variables (https://docs.mql4.com/predefined/variables)

But you should try anyway, just for the hell of it.

Thing about your test is that you dont allow another tick to come in. Server time related functions require knowledge of server time changes. A server time change usually comes along with new ticks. I think TimeCurrent() would be the thing not functioning as it should, even if it works as you want it to.


But I could be completely wrong. Either way, it's not really an issue for most if this works with new ticks and RefreshRates().

 

Thing about your test is that you dont allow another tick to come in.


You mean I don't allow another run of start()... Ticks come in regardless of ANYTHING u do in code. The only way to stop ticks coming in is to disconnect form the server. TimeCurrent() always reflects last known server time - the last incoming tick, and as long as u r connected they are coming and TimeCurrent() is updated. TimeCurrent() is functioning just fine - TimeDayOfYear(TimeCurrent()) works just fine in my code. It's DayOfYear() and DayOfWeek() that seem not to reflect the last known server time but the one at start of program run.

 

Ticks do come in, in another thread. But those functions might indeed be looking at the last known server time since your expert or script's thread started. And that would be perfectly fine. I don't see the issue. This is why RefreshRates() is recommended to see if it does more than just update the rates. It may also get last known server everything, despite its name.


 

Here, one more thing to support what I'm saying, this is on all the similar functions, but strangely missing from DayOfYear and DayOfWeek, but I think it was meant to be there(the part I made bold):


int Hour( )

Returns the hour (0,1,2,..23) of the last known server time by the moment of the program start (this value will not change within the time of the program execution).


Edit: I see you even reffered to those functions. OK, I give up. non-issue :)

Email the doc guy I guess, lol.

12
New comment