Sono completamente perso - pagina 4
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
Il fuso orario per datetime (secondi dopo il 1970) è basato su UTC. Proprio come il tempo di Unix. È UnixTime - tempo unix a 64 bit.
datetime - datetime = long (secondi di durata)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(un'altra data)
Per favore non alimentate il troll.
Quando rispondete, date potere al troll. Quando ignorate il troll, ha fame di attenzione e alla fine muore.
Penso che tu abbia dato un eccellente contributo. I tuoi post sono concisi e ben insegnati attraverso e ricevi un sacco di risoluzioni di "grazie" per i tuoi sforzi.
Sì, penso che tu abbia fatto tutto il possibile per questo ragazzo.
Come faccio a specificare un datetime in GMT?
dimenticavo che mql4 usa un concetto di tempo non corretto, . Mi accodo alla domanda retorica :-) il fuso orario dipende dal luogo da cui proviene. da qui tutti i problemi in quanto ci sono fonti multiple broker, computer, backtesting blah blah
Temevo che le regole di promozione del tipo di dati funzionassero in questo modo. Ok, quindi
datetime - datetime = long (secondi di durata)
datetime +/- seconds(long) = datetime(un'altra data)
datetime +/- seconds(int) = datetime(un'altra data)
Ma se dico X=Y-Z, o (Y-Z)/60, o qualcosa del genere, dove X è già dichiarato come un long o un int, e Y e Z sono datetime, è molto, molto male? E se è così, static_cast sistemerebbe tutto?
Raptoruk, non è indipendente dal fuso orario. Naturalmente la differenza tra le 14 e le 15 è di 3600 in qualsiasi fuso orario. Ma cosa succede se so che il trading si ferma alle 17:00 ora orientale di venerdì, ma non so in quale fuso orario si trova l'ora 0 (mezzanotte del 1 gennaio 1970)? Allora abbiamo un problema, no? Quindi il 1° gennaio 1970 era un giovedì. Se l'ora 0 è in GMT, allora il trading si ferma a 46 ore dopo, o 165600 modulo 604800. In altre parole, con 604800 secondi in una settimana, uso l'operazione aritmetica X%604800 per il resto dividendo per 604800, e il trading si ferma a 165600. Tuttavia, se il broker si trova a 2 fusi orari a est di quello e la loro spazzatura ha un timestamp di qualcosa che è 7200 più alto, allora il trading si ferma quando time%604800 è 172800, non 165600.
Sembra che ci sia incertezza sugli indici temporali riportati. Immagino di dover far capire al mio codice i tempi modulo 604800 in cui il trading inizia e si ferma, dopotutto, solo per essere sicuro. Sto pensando di guardare attraverso qualcosa come iTime('USDJPY',60,X) e trovare gap di 48 ore. Posso contare sul fatto che iTime sia il tempo "aperto", l'INIZIO dell'ora, giusto? In altre parole, il trading si ferma 1 ora dopo l'ultimo indice orario prima di un gap di 2 giorni, e riprende esattamente all'inizio del primo dopo il gap, e poi aggiungendo multipli di 604800 cambia semplicemente la settimana. Anche se ci sarebbero ulteriori complicazioni, come cosa succede se in qualche settimana, manca l'ultima ora, o manca la prima ora. Forse usare iTime('USDJPY',1,X) in modo da essere fuori di pochi minuti al massimo.
Oh, wow, un sacco di post messi in moto così velocemente da quello. Solo perché chiunque altro lo sappia, credo che raptoruk sia ok dopo tutto, ma un mucchio di invettive non è gradito, quindi se non sei ydrol o raptoruk o qualcuno nuovo con qualcosa di nuovo da dire, smetti di postare, non sono un troll perché non mi importa dei tuoi stati emotivi in un modo o nell'altro e se hai altro da lanciare in giro, sappi che cade nel vuoto.
Temevo che le regole di promozione del tipo di dati funzionassero in questo modo. Ok, quindi
datetime - datetime = long (secondi di durata)
datetime +/- seconds(long) = datetime(un'altra data)
datetime +/- seconds(int) = datetime(un'altra data)
Ma se dico X=Y-Z, o (Y-Z)/60, o qualcosa del genere, dove X è già dichiarato come un long o un int, e Y e Z sono datetime, è molto, molto brutto? E se è così, static_cast sistemerebbe tutto?
Raptoruk, non è indipendente dal fuso orario.
Ma cosa succede se so che il trading si ferma alle 5 pm Eastern time di venerdì, ma non so in quale fuso orario si trova l'ora 0 (mezzanotte del 1 gennaio 1970)? Allora abbiamo un problema, no?
Temevo che le regole di promozione del tipo di dati funzionassero in questo modo. Ok, quindi
datetime - datetime = long (secondi di durata)
datetime +/- seconds(long) = datetime(un'altra data)
datetime +/- seconds(int) = datetime(un'altra data)
Ma se dico X=Y-Z, o (Y-Z)/60, o qualcosa del genere, dove X è già dichiarato come un long o un int, e Y e Z sono datetime, è molto, molto male? E se è così, static_cast sistemerebbe tutto?
Queste non sono 'regole di promozione', sono solo io che sono ragionevole (spero!). Generalmente farei io stesso le tipologie di cui sopra.
Se il risultato del mio calcolo è ancora un numero che è secondi dal 1/1/1970 (indipendentemente dal fuso orario o dalla sua mancanza) allora lo terrei come datetime.
Altrimenti qualsiasi altra cosa (una durata, minuti dall'1/1/1970 o altro) probabilmente la memorizzerei come long. (A volte un int, specialmente per durate tipiche, ecc.)
Detto questo, sono perplesso su come i progettisti di MQL4 siano arrivati a non imporre UTC per tutti i datetime, e a costringere tutti i broker a inviare dati UTC, e a farli interpretare al client in localtime, perché il loro approccio attuale complica inutilmente tutto a valle.
Rende il calcolo dell'ora GMT e i tempi di apertura/chiusura della sessione durante il backtesting più difficile di quanto dovrebbe essere, se si vuole farlo correttamente per tutte le fonti di dati tick.
(Ad esempio, Alpari ha più fusi orari nei suoi dati storici, quindi devi stare attento alle tue fonti di dati quando fai il backtesting)
PS Ho modificato la mia falsità precedente :)
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.
raptoruk, "No . . beh forse tu sì, io no, quindi no, non lo facciamo." È assolutamente un problema. Non per me, non per te, non per noi, ma per la validità della tua precedente affermazione che è indipendente dal fuso orario. Perché non importa in quale fuso orario si trovi il tuo broker, il trading sul forex non segue l'orologio del tuo broker. Il venerdì e la domenica sono le 5 pm Eastern. 10 pm GMT. E che dire dell'ora legale/ora solare! Che dire di QUELLO! Alcuni paesi non aggiungono un'ora o la sottraggono, o lo fanno in un giorno diverso, quindi potresti ritrovarti con un codice che è un'ora in meno per parti dell'anno, se non c'è un modo carino per farlo. Io, non mi sono stabilito su un broker. Quello che sto provando è in GMT+2 ma penso che ora non mi piaccia, basandomi sul loro conto demo. E se ne provo uno per davvero, forse vorrò usarne uno diverso. Quindi non voglio che il fuso orario del broker sia hardcoded nel programma se è facile non farlo. Non fare di nuovo come quell'altro ragazzo, cercando di trasformare tutto in un'opportunità per lanciare un insulto invece di prendere la domanda al valore nominale.