Thread: Change Date format on MT4 .csv files?

Hanover,

thank you very much for this great indior.

Once I export currency history information everything works great, however on indexes and possibly also on different stocks, the indior seemingly plots max. 3 digits on the left.

Although I am not a programmer, I found due to the well commented code the lines regarding this, if I am not mistaken. Nevertheless I was not in a position to change the lines I get the correct prices for the index.

E.g. for your DAX_30 on a daily basis, I get this history line from the history centre:

2012.02.13,00:00,6740.0,6775.3,6709.8,6750.0,21105

,and this line from the indior:

02-13-2012,00:00,740.00000,775.30000,709.80000,750.00000 ,21105

May I ask you for support?

Thank you very much in advance!

Kindest regards,

Originally Posted by ;

Hanover,

thank you very much for this great indior.

When I export currency history data everything works great, but on indexes and possibly also on various stocks, the indior apparently plots max. 3 digits on the left side.

Although I am not a developer, I found because of this well commented code the lines regarding this, if I am not mistaken. Nevertheless I was not in a position to change the lines I get the correct prices for the index.

E.g. for the DAX_30 on a daily basis I get this history line from the history center:

2012.02.13,00:00,6740.0,6775.3,6709.8,6750.0,21105

,and...

Inserted Code extern string OHLCFmt = T3.5;
that line fucks it up. It is up to you to change it to something like T9.9 .

90 percent of the code should be binned as unnecessary bloatware.

Nubcake,

thank you very much for the fast and helpful reply.

Another thing is now the 7 digits following the decimal point. Is there also a spot in the code to change that's it only as a result of shift in the prior mentioned parameter?

Thank you very much beforehand!

Kindest Wishes,

Originally Posted by ;

,

thank you very much for the quick and helpful answer.

Another item is currently the 7 digits following the decimal point. Is there also a spot in the code to change that is it only as a result of shift in the previous mentioned parameter?

Thank you very much in advance!

Kindest Wishes,
secondstone

.... Change the number after the decimal point to. I said 9.9 just as an exaggerated example.

Inserted Code // ------------------------------------------------------------------ series NumberToStr(double n, string mask) // ------------------------------------------------------------------ // Formats a number using a mask, and returns the resulting string // Usage: string result = NumberToStr(amount(mask) // // Mask parameters: // n = number of digits to output, to the left of the decimal point ///////// n.d = output n digits to left of decimal point; d digits to the right // -n.d = floating minus sign at left of output // n.d- = minus sign at appropriate of output // n.d = floating plus/minus signal at left of output // // All these figures might appear anywhere in the string: // ( or ) = Change negative amount in parentheses // # or $ or ¥ or #8364; = comprise floating currency symbol at left of output // % = include trailing % signal // , = use commas to separate thousands, countless etc // Z or z = left fill with zeros Rather than spaces // * = left fill with asterisks Rather than spaces / / R or r = round cause rightmost exhibited digit // b or B = blank entire field if number is 0 // ~ = show tilde in leftmost place if overflow occurs // ; = change use of comma and period (European format) // L or l = left align final series //////// T ot t = trim (remove all spaces from) end result

Nubcake,

today I understand.

The 9.9 is seperated and signifies: 9 digits prior to the match point and also the 9 following the . Is meant for 9 minutes.

Thank You!

Kindest Wishes,

Originally Posted by ;

Inserted Code extern string OHLCFmt = T3.5; This line fucks it up. It's your choice to alter it to something like T9.9 .

90% of the code ought to be binned as unnecessary bloatware.

Who me? Guilty of bloatware?
Guilty for the summertime, no doubt; it is all too easy to allow the compiler strip outside of the uncalled modules.

@secondstone: sorry, I just saw this today. Seems like your query has meantime been answered. Please post again in the event that you have more queries.

Hanover,

thank you for your quick response.

Originally Posted by ;

Just to make sure I understand correctly: you mean that you are interested in getting the OHLC prices just as though the day begins/ends at 20:00 (or some other time) rather than 00:00 (midnight)?

That's correct.

Originally Posted by ;

In other words, some intervals from 20:00 hours to 20:00 hours would include less than 24 candles.

I don't care about openings, just the quickest/easiest programming adequate.

Originally Posted by ;

You also need to decide how you want the output date-stamped, e.g. will Monday 20:00 to Tuesday 20:00 represent Monday or Tuesday?

Monday.

Originally Posted by ;

Depending on the answers to the above questions, it might not necessarily be a trivial endeavor, and I am very busy with additional programming work right now. The source code can be obtained is any other developer.

If you could find then a little spare time, it would be absolutely excellent. Only the quickest/easiest approach, as I wrote.

Otherwise, if it is still more work than I thought, send me a quote through PM if you like.

Thank you a lot!

Kind regards,

secondstone,

Please try the attached script. This is my best and last effort, after spending over 4 hours trying several different methods of dealing with the weekend breaks in the information. The script generates Saturday candles in certain scenarios. If you export the prepaid data into a XLS and then attempt using formulae to group/summarize the information logically yourself, you may observe firsthand the ambiguities which are included.

The worth 20 in the ShiftHours parameter implies that the daily breaks at the information will happen at a time 20 hours earlier than the MT4 period of this candle being processed. Thus the fractures will happen at the 20:00 candles, since 20 hours earlier than 20:00 is 00:00. The 'daily' open will be at 20:00 H1 open; the near will be the close of this 19:00 H1 close. The daily high and low are the highest H1 high and cheapest H1 low across this interval, and the volume will be the amount of all of the H1 candle volumes across the interval.

This is my final article in this thread. After almost 5 decades of contributing freeware to FF, I owe it to use whatever spare time I've writing EAs for my personal use and profit.

David
https://www.nigeriaforextrading.com/...7325782508.mq4

secondstone,

Please try the attached script. This is my greatest and final effort, after spending over 4 hours attempting several different methods of managing the weekend breaks in the data. The script generates Saturday candles in some specific scenarios. If you export the hourly data to a XLS and then try using formulae to group/summarize the data logically yourself, you will observe first-hand the ambiguities which are included.

The worth 20 in the ShiftHours parameter implies that the daily breaks in the data will occur at a time 20 hours sooner than the MT4 period of this candle has been processed. Hence the breaks will occur in the 20:00 candles, since 20 hours sooner than 20:00 is 00:00. The 'daily' open will be at 20:00 H1 open; the near will be close of this 19:00 H1 close. The daily high and low will be the highest H1 high and lowest H1 low across this interval, and the quantity will be the sum of all the H1 candle volumes across the interval.

That is my final post in this thread. After almost 5 decades of contributing freeware to FF, I owe it to myself to use whatever spare time I've writing EAs for my personal use and profit.

David
https://www.nigeriaforextrading.com/...1562980403.mq4

David,

I'll try the script Afterwards. I have sent you a PM.

THANK YOU!

Kind regards,