Download MetaTrader 5

I am completely lost - page 5

To add comments, please log in or register
ydrol
593
ydrol  
I don't know what you mean by static cast. The timezone issue is a pain in mql. With old mql4 the approach was to have a global variables that the user set to the brokers offset,, you can also get gmt time using the new timegmt function but I've seen some reports this is buggy. Also I'm not sure how it behaves during backtesting. The whole thing is a mess unfortunately. But not impossible to code around.
whroeder1
14785
whroeder1  
RaptorUK: OK, what timezone is a datetime of 0 ?
It is the timezone of your broker's server. PERIOD. Any datetime you get from mt4 is your server's timezone. (Excluding TimeLocal() and the new mt5 TimeGMT)
ydrol: I'm puzzled how MQL4 designers arrived at not mandating UTC for all datetime,

You're puzzled at something over ten years old? Have you even heard of Y2K? If not you'd be just a puzzled at why dates were stored with only two digits per year so after 1999 was year 1900 or 19100.

You're probably puzzling why IP addresses are limited to 4.2 Billion in a world of 7 Billion people. Someone made that decision at DARPA when trying to connect the existing (dozens) mainframe computers in the country. Now we're converting to IPv6 from IPv4.

Get over yourself. This isn't Berger King, you don't get it your way. Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.

Ian Venner
2584
Ian Venner  
zortharg:

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.

There is a whole section in the docs about data types and typecasting do you press F1 while you are using the editor ?

ydrol
593
ydrol  
WHRoeder:
It is the timezone of your broker's server. PERIOD. Any datetime you get from mt4 is your server's timezone. (Excluding TimeLocal() and the new mt5 TimeGMT)

You're puzzled at something over ten years old? Have you even heard of Y2K? If not you'd be just a puzzled at why dates were stored with only two digits per year so after 1999 was year 1900 or 19100.

You're probably puzzling why IP addresses are limited to 4.2 Billion in a world of 7 Billion people. Someone made that decision at DARPA when trying to connect the existing (dozens) mainframe computers in the country. Now we're converting to IPv6 from IPv4.

Get over yourself. This isn't Berger King, you don't get it your way. Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.

nope you get over yourself. Seriously I'm puzzled why that decision was taken when it was designed. And I am perfectly within my rights to say so. Free speech and all that. You don't have the right to try to suppress me anymore than I you. It's based on an established time format that already used utc for a reason, and is far older than10 years, and now mql4 has timezone issues because of a decision that frankly puzzles me. And I am allowed to say so. You can be facetious about y2k all you want, it makes no difference. I work in systems integration for nearly twenty years and it looks like a bad design decision not to fix it to utc. Sorry if you can't handle someone else voicing their opinion.
ydrol
593
ydrol  
WHRoeder:
It is the timezone of your broker's server. PERIOD. Any datetime you get from mt4 is your server's timezone. (Excluding TimeLocal() and the new mt5 TimeGMT.
and GlobalVariableSet() which is gmt time derived from pc clock (unmodelled)
ydrol
593
ydrol  

Dredging this up again only because I'm currently migrating my TimeZone/Session functions to a tidy mql4++ class!

WHRoeder: Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.

I am dealing with it, but I'm still puzzled why I have to in the first place! Best practices around managing timezone information have been around for a long time. since 1988. Eg for ISO 8601

Time zones in ISO 8601 are represented as local time (with the location unspecified), as UTC, or as an offset from UTC.

If no UTC relation information is given with a time representation, the time is assumed to be in local time. While it may be safe to assume local time when communicating in the same time zone, it is ambiguous when used in communicating across different time zones.[My Emphasis] It is usually preferable to indicate a time zone (zone designator) using the standard's notation."

The bit underlined has been known in IT for nearly 30 years now if not more. The MQL datetime format is derived from UnixTime (they didnt pluck the magic date 1/1/1970 out of mid-air) so they should have been aware of that now.

Again in 1988, POSIX ratified UnixTime

"The POSIX committee was swayed by arguments against complexity in the library functions, and firmly defined the Unix time in a simple manner in terms of the elements of UTC time.[My Emphasis]

System Architects or developers designing client-server systems 10 years ago (which is not even that long ago), that exchange time critical information, should have had enough information to anticipate/avoid the current timezone mess. Traders in one timezone, get data in another timezone, which they sometimes want interpreted in another timezone(eg NY). The only excuses are:

- ignorance

- low priority (the TZ confusion benefits the brokers not the traders?)

- some technical consideration/constraint/requirement that is not obvious to us on the outside. Maybe drawing charts or something? Although its not that hard to add/subtract a known offset?

All of the above puzzle me as I said before. I feel shouldnt need to write code to calculate GMT time during backtesting! But TimeGMT() and TimeLocal() are not correctly modelled, (they are both set to the non-specific TZ derived from historical data) so we need to role our own timezone functions, to accurately calculate UTC and thus Session start and end times during backtesting.

PS The irony of being told to "get over myself" by WHRoeder is not lost :)

12345
To add comments, please log in or register