I am completely lost - page 5
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
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.
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 ?
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.
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.
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 :)