Libraries: ConvertServerTime - page 2

New comment
 
amrali #:
Am I correct in understanding that European devices, which automatically switch to summer/winter time in Europe, can never display this time on their watches? So, a European broker can never have a bar with this time on cryptocurrency?
 

I may be wrong, but it seems right.

//   const int sourceOffsetDST        = GetDST(aTime, sourceRuleDST);
   const int sourceOffsetDST        = GetDST(aTime - sourceTotalOffset, sourceRuleDST);

And then the corresponding changes.


And this.

      PrintFormat("ERROR: %s is invalid for %s GMT+0 (DST skipped this hour).", TimeToString(aTime), EnumToString(aRule));
 
fxsaber #:
Am I correct in understanding that European devices, which automatically switch to summer/winter time in Europe, can never display this time on their watches? So, a European broker can never have a bar with this time on cryptocurrency?

For mobile phones and watches, the short answer is yes — they cannot display the missing hour when daylight saving time (DST) begins in summer.

Some UK-based brokers handle this differently: they skip - do not quote - the 23:00 H1 bar on Sunday (to appear as if switching with the US instead of the UK) to avoid displaying a sixth D1 bar on their Forex charts. As a result, their trading week lasts 119 hours instead of the full 120 hours during the last 2–3 weeks of March.

Fortunately, gold charts from these brokers are not affected by this issue.

I previously explained this with a chart example here and also here.
 
fxsaber #:

I may be wrong, but it seems right.


Forum on trading, automated trading systems and testing trading strategies

Libraries: ConvertServerTime

fxsaber, 2025.10.23 06:20

I may be wrong, but it seems right.

//   const int sourceOffsetDST        = GetDST(aTime, sourceRuleDST);
   const int sourceOffsetDST        = GetDST(aTime - sourceTotalOffset, sourceRuleDST);

No, this is wrong. DST transitions occurs at the local time in time zone (not by UTC time as you suggest: aTime - sourceTotalOffset). 

By definition, an invalid time falls within a range of times for the current time zone that cannot be mapped to Coordinated Universal Time (UTC) due to the application of an adjustment rule. Typically, invalid times occur when the time moves ahead for daylight saving time at the start of summer. UTC time zone (and time zones that not follow DST policy) does not have invalid times.

See it here. Daylight Saving Time Changes 2025 in New York, New York, USA

 
amrali # :

Нет, это неверно. Переход на летнее время происходит по местному времени в часовом поясе (а не по времени UTC, как вы предлагаете: aTime - sourceTotalOffset).

У вас есть строго определенные правила для GMT+0 . 
   if (aRule == DST_EU)
     {
      dst_start = MakeDateTime(iYear, 03 , 31 - ( 4 + Y) % 7 , 01 );   // the last Sunday of March for the EU switch (DST+1)
      dst_end   = MakeDateTime(iYear, 10 , 31 - ( 1 + Y) % 7 , 02 );   // the last Sunday of October for the EU switch (DST+0)
     }

   if (aRule == DST_US)
     {
      dst_start = MakeDateTime(iYear, 03 , 14 - ( 1 + Y) % 7 , 02 );   // the second Sunday of March for the US switch (DST+1)
      dst_end   = MakeDateTime(iYear, 11 , 07 - ( 1 + Y) % 7 , 02 );   // the first Sunday of November for the US switch (DST+0)
     }
For example, for GMT+2 the time shift hour is different.
 
fxsaber # : 

   if(aRule == DST_US)
     {
      dst_start = MakeDateTime(iYear, 03, 14 - (1 + Y) % 7, 02);  // the second Sunday of March for the US switch (DST+1)
      dst_end   = MakeDateTime(iYear, 11, 07 - (1 + Y) % 7, 02);  // the first Sunday of November for the US switch (DST+0)
     }

This line will compute dst end = 2 Nov 2025, 02:00 local time in New York.


 
amrali #:

This line will compute dst end = 2 Nov 2025, 02:00 local time in New York.

For this reason, I proposed the corresponding changes.

 
fxsaber #:

For this reason, I proposed the corresponding changes.

If UTC is used instead of local time, the detection of time change will be offseted by some hours (not accurate).

 
amrali #:

If UTC is used instead of local time, the detection of time change will be offseted by some hours (not accurate).

#include <amrali\ConvertServerTime\ConvertServerTime.mqh> // https://www.mql5.com/en/code/65102

void OnStart()
{    
  ConvertServerTime(D'2020.03.29 01:00', 0, 0, DST_EU, DST_EU);       // ERROR - OK.
  ConvertServerTime(D'2020.03.29 01:00', 7200, 7200, DST_EU, DST_EU); // ERROR - why?
}
 
fxsaber #:

I answered you before. (2020.03.29 01:00 does not exit in EU time)

Switching to summer time:

Simply when the clock reaches 2020.03.29 00:59:59, the next second is 2020.03.29 02:00:00.

One hour is missing (invalid time) from the time upon entering summer (DST transition).

The reverse happens in winter:

when the clock reaches Sunday, 26 October 2025, 01:59:59 (after 3 days in Europe), the next second is 26 October 2025, 01:00:00.

So, the hour 01:00:00 - 01:59:59 will be repeated twice (ambiguous time).

Watch it live on your server clock! (Market watch)

1234
New comment