I am completely lost - page 4
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
The timezone for datetime (seconds past 1970) is based on UTC. Just like Unix time. It is UnixTime - 64 bit unix time.
datetime - datetime = long (seconds duration)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(another date)
Please do not feed the troll.
When you respond, you give the troll power. When you ignore the troll, he starves for attention and eventually dies.
I think you've done an excellent contribution. Your posts are concise and well taught through and you receive allot of "thank you" resolutions for your efforts.
Yeah, I think you did all you can for this guy.
How do I specify a datetime in GMT ?
whoop forgot mql4 uses a broken concept of time, . I conceed the rhetorical q :-) the timezone depends on where it came from. hence all the problems as there are multiple sources broker, computer, backtesting blah blah
I was afraid the data type promotion rules were going to work that way. Ok, so:
datetime - datetime = long (seconds duration)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(another date)
But if I say X=Y-Z, or (Y-Z)/60, or something like that, where X is already declared as a long or an int, and Y and Z are datetimes, is that very, very bad? And if so, would static_cast fix everything?
Raptoruk, it is not timezone independent. Of course the difference between 2 pm and 3 pm is 3600 in any one time zone. But what if I know that trading stops at 5 pm Eastern time on Friday, but I don't know what time zone time 0 (midnight on January 1, 1970) is in? Then we have a problem, don't we! So January 1, 1970 was a Thursday. If time 0 is in GMT, then trading stops at 46 hours after that, or 165600 modulo 604800. In other words, with 604800 seconds in a week, I use the X%604800 arithmetic operation for the remainder on dividing by 604800, and trading stops at 165600. However, if the broker is 2 time zones East of that and their junk is timestamped with something which is 7200 higher, then trading stops when time%604800 is 172800, not 165600.
Looks like there is uncertainty about the time indices reported. I guess I have to have my code figure out the times modulo 604800 at which trading starts and stops after all, just to be sure. I'm thinking I look through something like iTime('USDJPY',60,X) and find gaps of 48 hours. I can rely on iTime being the "open" times, the BEGINNING of the hour, right? In other words, trading stops 1 hour after the last time index before a 2-day gap, and it resumes exactly at the beginning of the first one after the gap, and then adding multiples of 604800 simply changes the week. Though there would be added complications, like what if in some week, it's MISSING the last hour, or missing the first hour. Maybe use iTime('USDJPY',1,X) so that I'm off by minutes at most.
Oh wow, lots of posts set off so fast by that one. Just so anyone else knows, I guess raptoruk is ok after all, but a bunch of invective is not welcome, so if you're not ydrol or raptoruk or someone new with something new to say, just stop posting, I'm not a troll because I don't care about your emotional states one way or another and if you have anything more to fling around, know that it falls on deaf ears.
I was afraid the data type promotion rules were going to work that way. Ok, so:
datetime - datetime = long (seconds duration)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(another date)
But if I say X=Y-Z, or (Y-Z)/60, or something like that, where X is already declared as a long or an int, and Y and Z are datetimes, is that very, very bad? And if so, would static_cast fix everything?
Raptoruk, it is not timezone independent.
But what if I know that trading stops at 5 pm Eastern time on Friday, but I don't know what time zone time 0 (midnight on January 1, 1970) is in? Then we have a problem, don't we!
I was afraid the data type promotion rules were going to work that way. Ok, so:
datetime - datetime = long (seconds duration)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(another date)
But if I say X=Y-Z, or (Y-Z)/60, or something like that, where X is already declared as a long or an int, and Y and Z are datetimes, is that very, very bad? And if so, would static_cast fix everything?
These are not 'promotion rules' just me being sensible (I hope!). I would generally to make the above typecasts myself.
If the result of my calculation is still a number that is seconds since 1/1/1970 (regardless of timezone or lack thereof) then I'd keep it as a datetime.
Otherwise anything else (a duration, minutes since 1/1/1970 whatever) I'd probably store as a long. (Sometimes an int, esp for typical durations etc,)
Having said that, I'm puzzled how MQL4 designers arrived at not mandating UTC for all datetime, and forcing all brokers send UTC data, and just having the client interpret it in localtime, because their current approach unnecessarily complicates everything downstream.
It makes computing GMT time, and Session open/close times during backtesting more difficult than it should be, if you want to do it correctly for all sources of tick data.
(Eg Alpari have multiple timezones in their historical data, so you have to be careful with your data sources when backtesting)
PS Edited my earlier falsie :)
ydrol, for the love of all that is sacred or whatever, please tell me - if you know - if static_cast can be used in mql4! Is it the same as in C++? This page https://docs.mql4.com/basis/types/casting never mentions this, I can't find it in the forums, I can't find it anywhere. I'm running into situations in my coding constantly, not just in turning datetime to long, but datetime to double, where it's unavoidable, so I want to do it right. Namely the program figures out what part of the week a sample is in, and emphasizes it in its calculations accordingly - but the time modulo the number of seconds in a week is still a datetime type variable and unless I can cast it as something else, it is stuck that way. But I need to perform a mathematical function of it, and have it be a double at the end, you see. If you don't know, then don't fret it, but please tell me if you do how I should properly typecast things in this sort of situation.
raptoruk, "No . . well maybe you do, I don't so no, we don't." It is absolutely a problem. Not to me, not to you, not to us, but to the validity of your earlier statement that it is timezone independent. Because it doesn't matter what timezone your broker is in, trading on the forex doesn't follow your broker's clock. It's 5 pm Eastern on Friday and Sunday. 10 pm GMT. And what about daylight saving time/standard time! What about THAT! Some countries don't add an hour or subtract it, or they do it on a different day, so you could end up with code that is an hour off for parts of the year, if there isn't a nice way to do it. Me, I haven't settled on a broker. The one I'm trying is in GMT+2 but I think now I don't like them, based on their demo account. And if I try one for real, maybe I'll want to use a different one instead. So I don't want the broker's time zone hardcoded into the program if it's an easy matter not to do that. Don't be like that other guy again, trying to twist everything into an opportunity to fling an insult instead of taking the question at face value.