Libraries: Local Timezones and Local Session Hours - page 4

New comment
 
amrali #:

Update 16 April 2024 - version 1.85

Replaced the GetNthSunday internal method with the more optimized GetMonthTime method.

//+------------------------------------------------------------------+
//| Returns year as integer of the specified date.                   |
//+------------------------------------------------------------------+
int CTimeZoneInfo::TimeYear(const datetime t)
  {
   MqlDateTime st;
   TimeToStruct(t, st);
   return(st.year);
  }

Can be replaced with this or other analogues.

 

To do conversions on you own, you can construct 2 columns for the 365 days in a year (or better the segments created due to dst switch times) :

old_GMT+DST | new_GMT+DST and each row contains the GMT offset for that day.

to convert chart bar times: converted = bartime + ( new_GMT+DST - old_GMT+DST);

This is the main idea of time conversions in the library.


NOTICE: Economic calendar needs a special treatment:

all calendar dates downloaded from the server includes FIXED offset from GMT throughout the year (equal to the offset of the trade server from GMT at the time of calendar request i.e, = TimeTradeServer - TimeGMT)

To correctly re-calculate proper dates for the calendar (respecting broker's dst changes throughout the year) :

1. subtract the "current" GMT offset of the trade server from all plausible dates in the calendar (the "current" offset here could be winter or summer e.g., +2 or +3; still unknown).

2. add the broker's base (standard, winter) GMT offset + DST adjustment according to the times of the broker's dst rule (i.e., dst bias is added only to calendar dates matching broker's dst schedule).

This is like the 2 columns idea above (GMT + broker's columns), but you have some challenges to overcome

a. identifying the standard (winter) GMT offset of the broker (as the one calculated in step #1 above could be summer or winter)

b. identifying the correct DST schedule of the broker (requires some form of scanning the price charts to identify the timeline "shape" of the weekly bars of H1 timeframe)

a+b above can be solved in 2 separate steps to identify each component of the total offset, or a+b can be solved in the same step by calculating the offset+DST (total offset) from the weekly start hour of the broker's bars on the H1 timeframe of the GOLD charts and comparing these hours to the GMT corresponding to the Forex market start hour for GOLD at 18:00 Sunday in NYC time.

The second solution is the one used in the TimeZoneInfo Library because the broker offsets are actually measured in real time and not calculated based on the assumed dst schedule.

 
fxsaber #:

Can be replaced with this or other analogues.

int GetYear3( const datetime time )
{
  return((int)((time / DAY * 4 + 2) / (365 * 4 + 1)) + 1970);
}

Speed-up is not worth it (< half-order of magnitude).

TimeYear() based on MqlDateTime struct is fast enough.

I have replaced the GetNthSunday with the more optimized GetMonthTime() as the speed-up is 20x-30x.

 
amrali #:

Speed-up is not worth it (< half-order of magnitude).

TimeYear() based on MqlDateTime struct is fast enough.

I have replaced the GetNthSunday with the more optimized GetMonthTime() as the speed-up is 20x-30x.

Re-check:

Speed-up is 5-10x.

Thanks

 

Update 17 April 2024 - version 1.87

Replaced the TimeYear internal method with the more optimized GetYear method.

 
amrali #:

NOTICE: Economic calendar needs a special treatment:

all calendar dates downloaded from the server includes FIXED offset from GMT throughout the year (equal to the offset of the trade server from GMT at the time of calendar request i.e, = TimeTradeServer - TimeGMT)

To correctly re-calculate proper dates for the calendar (respecting broker's dst changes throughout the year) :

1. subtract the "current" GMT offset of the trade server from all plausible dates in the calendar (the "current" offset here could be winter or summer e.g., +2 or +3; still unknown).

2. add the broker's base (standard, winter) GMT offset + DST adjustment according to the times of the broker's dst rule (i.e., dst bias is added only to calendar dates matching broker's dst schedule).

This is like the 2 columns idea above (GMT + broker's columns), but you have some challenges to overcome

a. identifying the standard (winter) GMT offset of the broker (as the one calculated in step #1 above could be summer or winter)

b. identifying the correct DST schedule of the broker (requires some form of scanning the price charts to identify the timeline "shape" of the weekly bars of H1 timeframe)

a+b above can be solved in 2 separate steps to identify each component of the total offset, or a+b can be solved in the same step by calculating the offset+DST (total offset) from the weekly start hour of the broker's bars on the H1 timeframe of the GOLD charts and comparing these hours to the GMT corresponding to the Forex market start hour for GOLD at 18:00 Sunday in NYC time.

The second solution is the one used in the TimeZoneInfo Library because the broker offsets are actually measured in real time and not calculated based on the assumed dst schedule.

The steps could be done in a different order:

1. subtract the "current" GMT offset of the trade server from all plausible dates in the calendar (the "current" offset here could be winter or summer e.g., +2 or +3; still unknown).

2. identifying the correct DST schedule of the broker: Determine Broker's Daylight (DST) schedule

3. If the broker is DST_US or DST_UK and currently in summer: then subtract one hour from "current" GMT offset to get the base (winter) GMT offset, otherwise no subtraction.

4. add the broker's base (standard, winter) GMT offset to all dates in step #1

5. add DST adjustment one hour according to the times of the broker's dst rule (i.e., dst bias is added only to calendar dates matching summer of the broker's dst schedule).

Step #5 will be skipped if the broker is DST_NONE.

 

Update 18 April 2024 - version 1.88

Added the CreateDateTime internal method to construct datetime values from date components (year, month and day).

This is 100-120x times faster than assigning values to MqlDateTime struct then calling the StructToTime function.

1234
New comment
Reason: