Scripts: TimeServerDaylightSavings

[Automated-Trading]

TimeServerDaylightSavings:

Time-related functions for empirical detection of server time zone and daylight savings mode (DST) from history of quotes

Author: Stanislav Korotky

[Alain Verleyen]

How is it different from the amrali version published 6 months ago ?

[Stanislav Korotky]

Alain Verleyen #:
How is it different from the amrali version published 6 months ago ?

I didn't see this one, and mine was originally written a couple of years before, so I did only refine it after the book. Mine is more simple (based on empirics from stats only) and probably less accurate, this should be tested.

[amrali]

Using your script, I obtain wrong DST for my broker ICMarkets.

Note that, as per the ICMarkets' news page link: the server time was adjusted from GMT+2 to GMT+3 on Sunday, 10 March 2024 .

Expert logs of your script "TimeServerDaylightSavings":

2024.10.06 23:43:41.175 TimeZonesHistory (EURUSD,H1)    Raw Trading Ltd ⁞ ICMarketsSC-Demo
2024.10.06 23:43:41.175 TimeZonesHistory (EURUSD,H1)    ¹ ⁞ Built-in functions ⁞
2024.10.06 23:43:41.175 TimeZonesHistory (EURUSD,H1)    TimeLocal()=2024.10.06 23:43:41 / ok
2024.10.06 23:43:41.175 TimeZonesHistory (EURUSD,H1)    TimeCurrent()=2024.10.04 23:56:59 / ok
2024.10.06 23:43:41.175 TimeZonesHistory (EURUSD,H1)    TimeTradeServer()=2024.10.06 23:43:41 / ok
2024.10.06 23:43:41.175 TimeZonesHistory (EURUSD,H1)    TimeGMT()=2024.10.06 20:43:41 / ok
2024.10.06 23:43:41.175 TimeZonesHistory (EURUSD,H1)    TimeGMTOffset()=-10800 / ok
2024.10.06 23:43:41.175 TimeZonesHistory (EURUSD,H1)    TimeDaylightSavings()=0 / ok
2024.10.06 23:43:41.175 TimeZonesHistory (EURUSD,H1)    ² ⁞ Add-on over built-in functions ⁞
2024.10.06 23:43:41.175 TimeZonesHistory (EURUSD,H1)    TimeServerGMTOffset()=-10800 / ok
2024.10.06 23:43:41.175 TimeZonesHistory (EURUSD,H1)    ³ ⁞ Estimation of server TZ with DST based on week opening hours in history ⁞
2024.10.06 23:43:41.176 TimeZonesHistory (EURUSD,H1)    TimeServerDaylightSavings()=0 / ok
2024.10.06 23:43:41.176 TimeZonesHistory (EURUSD,H1)        [offsetGMT] [offsetDST] [supportDST]
2024.10.06 23:43:41.176 TimeZonesHistory (EURUSD,H1)    [0]       -7200           0        false

That is totally wrong, because ICMarkets' servers actually adopts a DST policy as mentioned aboved on their webpage.

Here are the logs of my script "BrokerDaylightSchedule" which are actually correct:

2024.10.06 23:45:44.710 BrokerDaylightSchedule (EURUSD,H1)      Server : ICMarketsSC-Demo
2024.10.06 23:45:44.710 BrokerDaylightSchedule (EURUSD,H1)      Time   : 2024.10.06 23:45:44
2024.10.06 23:45:44.710 BrokerDaylightSchedule (EURUSD,H1)      Offset : GMT+3
2024.10.06 23:45:44.710 BrokerDaylightSchedule (EURUSD,H1)      DST_US : server dst begins on the second Sunday of March (+1) and ends on the first Sunday of November (-1)

Due to lack of time, may be in a future post, I will explain in more details why your approach and understanding of DST switches is not the most correct.

Hint: you based your algorithm on that idea/assumption: as long as the start times of the first H1 bars of the trading weeks do not change, so that the server time does not adopt a DST schedule.

THAT IS TOTALLY WRONG !! See the debug logs of your script as a proof (#define PRINT_DST_DETAILS).

Opening time (First H1 bars) are actually determined by Fx opening times in New York (NY), which are controlled by the american DST schedule. Fx week starts always Sunday 5 PM, NY time (winter or summer).

On the contrary of your assumption, the opposite is true: If ICMarkets (or any other server) does not apply the same DST (american DST) to their server times to match Fx start times in NY, you find differences in the start times of the first H1 bars. Only by anaylsing the shape/distribution of this discrepancy (at the expected times of DST changes), you can conclude if the server adopts DST or not, and if so you can make a try to identify the most probable schedule followed by that server. That is the main idea of my script "BrokerDaylightSchedule".

As a simple analogy: your work always starts at 5 pm every day (winter or summer), also your collegues start on 5 pm. But one day, at the beginning of summer, you decided to advance your watch +1 hour (8 am to 9 am).  So, when you go to work on 5 pm according to your clock, it is still early (4 pm) according to your colleages' time. This discrepancy continues for some days until your colleages also advance their watches. But on the other hand, no discrepancy happens if your colleages also advance their watches on the same time as you do. The opposite situation happens in winter, when you delay you watch by -1 hour (9 am to 8 am).

My best regards,

[Stanislav Korotky]

amrali #:

Opening time (First H1 bars) are actually determined by Fx opening times in New York (NY), which are controlled by the american DST schedule. Fx week starts always Sunday 5 PM, NY time (winter or summer).

Ok, I got it, thank you. Let me look into it.

[amrali]

To get correct results with your algo, I think you have to isolate the effect of DST switch in New York (during summer) from the  server time.

So, any discrepancy found in the times of H1 bars of forex weeks on the server will be solely an indication of a DST switch on that server.

I tested that idea by modifying your coder, and it seemed to work nicely.

original code at line 136 in 'TimeServerDST.mqh' file:

        // lets analyze the first H1 bar of the trading week
        // find out an hour for the first bar after weekend
        previous = current;
        current = _TimeHour();
        if(previous != current) // keep track of TZ changes
        {

modified code:

        // lets analyze the first H1 bar of the trading week
        // find out an hour for the first bar after weekend
        previous = current;
        current = _TimeHour();
        //---------------------------------------------------------------------
        if(_TimeMonth() >= 3 && _TimeMonth() <= 11)
        {
          int iYear = _TimeYear();
          MqlDateTime dt1 = {iYear, 03, (14 - (1 + 5*iYear/4) % 7)};  // the second Sunday of March for the US switch
          MqlDateTime dt2 = {iYear, 11, (07 - (1 + 5*iYear/4) % 7)};  // the first Sunday of November for the US switch

          datetime dst_begin = StructToTime(dt1);
          datetime dst_end   = StructToTime(dt2);

          if (array[i] >= dst_begin && array[i] < dst_end)
          {
            current += 1; // isolate (add) the effect of us switch on our server time.
          }
        }
        //---------------------------------------------------------------------
        if(previous != current) // keep track of TZ changes
        {

original code at line 220 in 'TimeServerDST.mqh' file:

     int utc = HourToUTC(current, DST);

modified code:

     int utc = HourToUTC(current);

Here are the expert logs of running the above modified code on ICMarkets:

2024.10.08 01:42:31.844 TimeZonesHistory (EURUSD,H1)    Raw Trading Ltd ⁞ ICMarketsSC-Demo
2024.10.08 01:42:31.844 TimeZonesHistory (EURUSD,H1)    ¹ ⁞ Built-in functions ⁞
2024.10.08 01:42:31.844 TimeZonesHistory (EURUSD,H1)    TimeLocal()=2024.10.08 01:42:31 / ok
2024.10.08 01:42:31.844 TimeZonesHistory (EURUSD,H1)    TimeCurrent()=2024.10.08 01:42:31 / ok
2024.10.08 01:42:31.844 TimeZonesHistory (EURUSD,H1)    TimeTradeServer()=2024.10.08 01:42:31 / ok
2024.10.08 01:42:31.844 TimeZonesHistory (EURUSD,H1)    TimeGMT()=2024.10.07 22:42:31 / ok
2024.10.08 01:42:31.844 TimeZonesHistory (EURUSD,H1)    TimeGMTOffset()=-10800 / ok
2024.10.08 01:42:31.844 TimeZonesHistory (EURUSD,H1)    TimeDaylightSavings()=0 / ok
2024.10.08 01:42:31.844 TimeZonesHistory (EURUSD,H1)    ² ⁞ Add-on over built-in functions ⁞
2024.10.08 01:42:31.844 TimeZonesHistory (EURUSD,H1)    TimeServerGMTOffset()=-10800 / ok
2024.10.08 01:42:31.844 TimeZonesHistory (EURUSD,H1)    ³ ⁞ Estimation of server TZ with DST based on week opening hours in history ⁞
2024.10.08 01:42:31.845 TimeZonesHistory (EURUSD,H1)    TimeServerDaylightSavings()=-3600 / ok
2024.10.08 01:42:31.845 TimeZonesHistory (EURUSD,H1)        [offsetGMT] [offsetDST] [supportDST]
2024.10.08 01:42:31.845 TimeZonesHistory (EURUSD,H1)    [0]      -10800       -3600         true

the modified header is in the attachments.

Best regards,

[Stanislav Korotky]

amrali #:

Here are the expert logs of running the above modified code on ICMarkets:

the modified header is in the attachments.

Cool, thank you. I'll check it.

[amrali]

a minor correction to avoid "array out of range" error in "TimeServerDST_amr":

          if (array[i] >= dst_begin && array[i] < dst_end)
          {
            //current += 1; // isolate (add) the effect of us switch on our server time.
            current = WRAP24(current + 1);
          }

[amrali]

Thanks for the updated script. It works well with my brokers.

[Stanislav Korotky]

This library is now used in CalendarCSVForDates.mq5 and CalendarMonitorCachedTZ.mq5.