
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
. New Time Zones Added:
2. Daylight Saving Time (DST) Rules Implemented:
. New Time Zones Added:
Very helpful code, thanks!
I did notice a bug with SessionHours.mqh:
If you set your session time goes over midnight (i.e. end hour is before start hour), the session is never considered open. e.g:
session.SecRemainingSession() would always return 0, and
session.CheckLocalSession() would always return false
Edit:
This may be only in specific scenarios. I notice this issue when I'm running the tester, but when attaching to a chart the issue seems to be gone.
Subject: Regarding your code - TimeZoneInfo.mqh - minor adjustments
Hi amrali ,
I wanted to reach out and say thank you for sharing your TimeZoneInfo.mqh . I found the code to be very well-structured and easy to understand, which made it a pleasure to work with.
I made a few minor adjustments to suit my specific needs, and it was straightforward due to the clear organization of your code.
However, I noticed a small issue when I was renaming your named constants. I inadvertently missed adding the "ZONE_ID_" prefix to some of them. As a result, those constants are now hardcoded, which isn't ideal.
To correct this, I've made the necessary changes and have attached the updated file, "TimeZoneInfo.mqh", to this message.
Again, I appreciate you sharing your work. It's a great example of well-written MQL5 code.
Thanks,
Very helpful code, thanks!
I did notice a bug with SessionHours.mqh:
If you set your session time goes over midnight (i.e. end hour is before start hour), the session is never considered open. e.g:
You missed that session times are local Forex times in that city which usually starts with banks at 7-9 am to 5-6 pm. (i.e., hour 17-18 ).
I do understand the logic behind that, however, in my situation using the local timezone (Tokyo in this case) would add problems with DST (Tokyo doesn't use it, but NY does - which is the base timezone for the sessions I'm using). I also noticed an added complicate in that this morning's session (20:00 - 00:00 NY Time) is detected as a Sunday (since it is Sunday in that timezone, even though the local (Tokyo) time is Monday.
So I modified your session code this morning and:
I haven't thoroughly checked whether converting to UTC will add problems, guess we'll see in the summer :)
I do understand the logic behind that, however, in my situation using the local timezone (Tokyo in this case) would add problems with DST (Tokyo doesn't use it, but NY does - which is the base timezone for the sessions I'm using). I also noticed an added complicate in that this morning's session (20:00 - 00:00 NY Time) is detected as a Sunday (since it is Sunday in that timezone, even though the local (Tokyo) time is Monday.
A trading session is when the market is most active, so when the greatest volume of trades occur at one time. It is not when the forex market begins trading in that city.
It seems that you wrongly use NY session object, and try to deduct Tokyo session time from it. This is wrong as it should give the above error.
The local time in NY object was 20:00 Sunday, which maps to = 20:00 (NY_TIME) - (-5) NY_GMT_OFF + 9 (TOK_UTC_OFFSET) = 09:00 am Monday in Tokyo.
Time in NY object is Sunday which is a weekend, although it 's Monday in Tokyo. This is exactly the same error you gave got.
The correct way to do it, is by directly using a [Tokyo session object] and leave the default start and end time at their default values (8 am - 5 pm).
Please refer to Forex sessions in these links to understand time mappings in different major centres:
https://www.tradinghours.com/
https://forex.timezoneconverter.com/?timezone=GMT&refresh=5
csol007 #:
If you set your session time goes over midnight (i.e. end hour is before start hour), the session is never considered open. e.g:
To help understand the logic behind the session objects library, you can think of each type of object (depending on its ZONE_ID_xxx) as a wall clock like in this picture. To know if Tokyo session is open simply look at the Tokyo clock (object). That's more natural/ direct way of thinking about it.
Subject: Regarding your code - TimeZoneInfo.mqh - minor adjustments
I made a few minor adjustments to suit my specific needs, and it was straightforward due to the clear organization of your code.
However, I noticed a small issue when I was renaming your named constants. I inadvertently missed adding the "ZONE_ID_" prefix to some of them. As a result, those constants are now hardcoded, which isn't ideal.
To correct this, I've made the necessary changes and have attached the updated file, "TimeZoneInfo.mqh", to this message.
It would be much easier for you to configure the built-in custom timezone for the desired target location, instead of re-writing the library code, which is prone to errors and requires more time and effort as you did.
A demo to create a custom timezone, for example Dubai.
Output:
You can repeat the same logic for the other cities as you did for: Hong Kong, Singapore, Zurich, Toronto, Paris, Shanghai, Moscow, Mumbai, Johannesburg, Madrid, Amsterdam and Seoul.\
However, there is only ONE custom tz active at a time, the one in which you're interested.