Why is a “datetime” limited to 31 December, 3000?

 

This is a question of curiosity. Why is a “datetime” limited to 31 December, 3000?

In the original MQL4, a “datetime” data-type was originally 4 bytes, presumably an “int” data-type with a limit of 2147483647 that would give a maximum date-time of D’2038.01.19 03:14:07’. Later on, with the appearance of MQL5 and update to MQL4+, the “datetime” datatype was updated to 8 bytes, presumably a “long” data-type with a limit of 9223372036854775807. However, according to the documentation, the date-time limit is 31 December, 3000. Its limit is probably D’3000.12.31 23:59:59’ or a value of 32535215999 seconds, which in hexadecimal would be 0x7933FFF7F and would occupy 4.5 bytes.

My question is — why limit it to 4.5 bytes, when it occupies 8 bytes? Is there a historical significance to this or compatibility with other languages?

Even if it is for allowing the “datetime” to be referenced in milliseconds and still fit in a “long”, it still does not make much sense. Even if we were to account for allowing for nanoseconds to fit in a “long”, this date limit would still fall short. Another possibility is for the value to be stored in a “double”, but that has 15 significant digits, which still allow for 4 extra digits, given that 32535215999 only has 11 digits.

So out of curiosity, does anyone know why MetaQuotes set this limitation on “datetime”?

 
At least the space unused could be used to encode a timezone and daylight savings.

Since MT5 doesn't show up on Futurama, I guess the year 3000 will anyways never been seen by this software.

Other than that, I cannot think of any other reason.
 
Dominik Christian Egert #:At least the space unused could be used to encode a timezone and daylight savings.Since MT5 doesn't show up on Futurama, I guess the year 3000 will anyways never been seen by this software. Other than that, I cannot think of any other reason.
Yes, that is actually quite a good suggestion!
 

EDIT: Updated code to show where the limits of the datetime datatype are set by the MQL 5 language.

void OnStart() // MQL5 Script Code
{
   datetime
      dtNow   = TimeCurrent(),
      dtMin   = D'1970.01.01 00:00:00',
      dtMax   = D'3000.12.31 23:59:59',
      dtLimit = dtMax + 8*60*60;
      
   Print( "Now   Date: ", dtNow,   " (", (long) dtNow,   ")" );
   Print( "Min   Date: ", dtMin,   " (", (long) dtMin,   ")" );
   Print( "Max   Date: ", dtMax,   " (", (long) dtMax,   ")" );
   Print( "Limit Date: ", dtLimit, " (", (long) dtLimit, ")" );
   
   dtLimit++;
   Print( "Limit Date: ", dtLimit, " (", (long) dtLimit, ")" );
};
Now   Date: 2022.08.15 23:35:06 (1660606506)
Min   Date: 1970.01.01 00:00:00 (0)
Max   Date: 3000.12.31 23:59:59 (32535215999)
Limit Date: 3001.01.01 07:59:59 (32535244799)
Limit Date: wrong datetime (32535244800)
 
Fernando Carreiro #:

EDIT: Updated code to show where the limits of the datetime datatype are set by the MQL 5 language.

When googleing 32535244799 some interesting results come up.

One I found is here:

https://stackoverflow.com/questions/35048512/what-are-valid-arguments-for-localtime-function


As it seems, its not MQLs limitation, but MS Windows system function / return structure limitation.

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/localtime-localtime32-localtime64?redirectedfrom=MSDN&view=msvc-170

localtime, _localtime32, _localtime64
localtime, _localtime32, _localtime64
  • 2021.08.03
  • TylerMSFT
  • docs.microsoft.com
Learn more about: localtime, _localtime32, _localtime64
 

Dominik Christian Egert #: When googleing 32535244799 some interesting results come up. One I found is here: https://stackoverflow.com/questions/35048512/what-are-valid-arguments-for-localtime-function

As it seems, its not MQLs limitation, but MS Windows system function / return structure limitation.  https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/localtime-localtime32-localtime64?redirectedfrom=MSDN&view=msvc-170

Thank you @Dominik Christian Egert for your research. That was an interesting find.

From your references, it seems that it is not so much a limitation of the datetime (or _time64), but more a limitation of its conversion to and from a time structure or a string, for example by the _localtime or ctime functions.

But it is good to know that it is not a MQL limitation but an OS limitation not mentioned in the MQL documentation.

Also it seems, from what I have read so far, that each OS has defined their own limits on what constitutes a valid future timestamp and that the limit is not globally defined.

Now I am left wondering why Microsoft imposed such a limit?

 
Fernando Carreiro #:

Thank you @Dominik Christian Egert for your research. That was an interesting find.

From your references, it seems that it is not so much a limitation of the datetime (or _time64), but more a limitation of its conversion to and from a time structure or a string, for example by the _localtime or ctime functions.

But it is good to know that it is not a MQL limitation but an OS limitation not mentioned in the MQL documentation.

Also it seems, from what I have read so far, that each OS has defined their own limits on what constitutes a valid future timestamp and that the limit is not globally defined.

Now I am left wondering why Microsoft imposed such a limit?

... imposed such a limit.

I really have no clue why it would be limited anyways, especially when the leftover space isn't even used for anything.

Encoding the Timezone and DST details would have made sense, but that's definitely not done or at least not documented. - I really don't understand.

... mql documentation.

It would be a great feature if the documentation would offer a comment section and a code section as well, with voting, like on stack overflow. It be such a nice addendum to the community as well as for the dev team.

Maybe we can make a call out on the forum to ask for such a feature towards metaquotes.


 
Dominik Christian Egert #: ... mql documentation. It would be a great feature if the documentation would offer a comment section and a code section as well, with voting, like on stack overflow. It be such a nice addendum to the community as well as for the dev team. Maybe we can make a call out on the forum to ask for such a feature towards metaquotes.

Given that MetaQuotes does not even have a public issue or bug tracking system in place, like other software companies, I doubt they would even contemplate such a possibility.

However, it's puzzling that only a few trading software platforms actually have a public issue tracking system in place. I only know of one actually, namely MultiCharts.

 
Well, I suppose you are right, but on the other hand, they really try to get their community to stay connected and be engaged.

Especially when it comes to market products, but I guess that's because of monetary interests.

 
Dominik Christian Egert #: Well, I suppose you are right, but on the other hand, they really try to get their community to stay connected and be engaged. Especially when it comes to market products, but I guess that's because of monetary interests. 

True 😅

Reason: