Sono completamente perso - pagina 5
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Sei perplesso per qualcosa che ha più di dieci anni? Avete mai sentito parlare dell'Y2K? Se no, saresti solo perplesso sul perché le date sono state memorizzate con solo due cifre per anno, quindi dopo il 1999 era l'anno 1900 o 19100.
Probabilmente ti stai chiedendo perché gli indirizzi IP sono limitati a 4,2 miliardi in un mondo di 7 miliardi di persone. Qualcuno ha preso questa decisione alla DARPA quando si cercava di collegare i computer mainframe esistenti (decine) nel paese. Ora ci stiamo convertendo a IPv6 da IPv4.
Supera te stesso. Qui non siamo a Berger King, non si fa a modo tuo. Qualcuno ha preso una decisione che sembrava ragionevole in quel momento e ora non lo è più. Fatevene una ragione.
ydrol, per l'amore di tutto ciò che è sacro o altro, per favore dimmi - se lo sai - se static_cast può essere usato in mql4! È lo stesso che in C++? Questa pagina https://docs.mql4.com/basis/types/casting non ne parla mai, non lo trovo nei forum, non lo trovo da nessuna parte. Mi sto imbattendo in situazioni nel mio coding costantemente, non solo nel trasformare datetime in long, ma datetime in double, dove è inevitabile, quindi voglio farlo bene. Vale a dire che il programma capisce in quale parte della settimana si trova un campione, e lo enfatizza nei suoi calcoli di conseguenza - ma il tempo modulo il numero di secondi in una settimana è ancora una variabile di tipo datetime e a meno che non possa castarlo come qualcos'altro, è bloccato in quel modo. Ma ho bisogno di eseguire una funzione matematica su di essa, e che sia un doppio alla fine, vedete. Se non lo sapete, allora non preoccupatevi, ma per favore ditemi, se lo sapete, come dovrei digitare correttamente le cose in questo tipo di situazione.
C'è un'intera sezione nei documenti sui tipi di dati e la digitazione, premi F1 mentre usi l'editor?
È il fuso orario del server del vostro broker. PERIODO. Qualsiasi datetime che ottieni da mt4 è il fuso orario del tuo server. (Escludendo TimeLocal() e il nuovo mt5 TimeGMT)
Sei perplesso per qualcosa che ha più di dieci anni? Avete mai sentito parlare dell'Y2K? Se no, saresti solo perplesso sul perché le date sono state memorizzate con solo due cifre per anno, quindi dopo il 1999 era l'anno 1900 o 19100.
Probabilmente sei perplesso sul perché gli indirizzi IP sono limitati a 4,2 miliardi in un mondo di 7 miliardi di persone. Qualcuno ha preso questa decisione alla DARPA quando si cercava di collegare i computer mainframe esistenti (decine) nel paese. Ora ci stiamo convertendo a IPv6 da IPv4.
Supera te stesso. Qui non siamo a Berger King, non si fa a modo tuo. Qualcuno ha preso una decisione che sembrava ragionevole in quel momento e ora non lo è più. Fatevene una ragione.
È il fuso orario del server del vostro broker. PERIODO. Qualsiasi datetime che ottenete da mt4 è il fuso orario del vostro server. (Escludendo TimeLocal() e il nuovo mt5 TimeGMT.
Riporto a galla questo argomento solo perché attualmente sto migrando le mie funzioni TimeZone/Session in una classe ordinata di mql4++!
WHRoeder: Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.
Me ne sto occupando, ma sono ancora perplesso sul perché devo farlo! Le migliori pratiche per la gestione delle informazioni sui fusi orari esistono da molto tempo, dal 1988. Ad esempio per ISO 8601
Ifusi orari in ISO 8601 sono rappresentati come ora locale (con la posizione non specificata), come UTC, o come un offset da UTC.
Se non viene data alcuna informazione sulla relazione UTC con una rappresentazione del tempo, si presume che il tempo sia in ora locale. Mentre può essere sicuro assumere l'ora locale quando si comunica nello stesso fuso orario, è ambiguo quando viene usato per comunicare attraverso diversi fusi orari.[Enfasi mia] Di solito è preferibile indicare un fuso orario (designatore di zona) usando la notazione dello standard".
Il bit sottolineato è noto nell'informatica da quasi 30 anni, se non di più. Il formato datetime di MQL è derivato da UnixTime (non hanno tirato fuori dal nulla la data magica 1/1/1970) quindi avrebbero dovuto esserne a conoscenza.
Sempre nel 1988, POSIX ha ratificato UnixTime
"Il comitato POSIX è stato influenzato da argomenti contro la complessità delle funzioni di libreria, e definì fermamente il tempo Unix in modo semplice in termini di elementi del tempo UTC. [Mia enfasi]
Gli architetti di sistema o gli sviluppatori che progettano sistemi client-server 10 anni fa (che non è nemmeno tanto tempo fa), che scambiano informazioni critiche sul tempo, avrebbero dovuto avere abbastanza informazioni per anticipare/evitare l'attuale pasticcio del fuso orario. I trader in un fuso orario, ricevono dati in un altro fuso orario, che a volte vogliono interpretare in un altro fuso orario (per esempio NY). Le uniche scuse sono:
- ignoranza
- bassa priorità (la confusione dei fusi orari va a vantaggio dei broker e non dei trader?)
- qualche considerazione/convinzione/requisito tecnico che non è ovvio per noi all'esterno. Forse disegnare grafici o qualcosa del genere? Anche se non è così difficile aggiungere/sottrarre un offset noto?
Tutto quanto sopra mi lascia perplesso come ho detto prima. Sento che non dovrei avere bisogno di scrivere codice per calcolare l'ora GMT durante il backtesting! Ma TimeGMT() e TimeLocal() non sono modellati correttamente, (sono entrambi impostati sul TZ non specifico derivato dai dati storici) quindi abbiamo bisogno di ruoli le nostre funzioni di fuso orario, per calcolare accuratamente UTC e quindi i tempi di inizio e fine sessione durante il backtesting.
PS L'ironia di essere detto di "superare me stesso" da WHRoeder non è persa :)