tamamen kayboldum - sayfa 5
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
On yaşından büyük bir şeye mi şaşırdın? Y2K'yı hiç duydunuz mu? Değilse, tarihlerin neden yılda yalnızca iki basamakla saklandığına şaşıracaksınız, bu yüzden 1999'dan sonra 1900 veya 19100 yılıydı.
7 Milyarlık bir dünyada IP adreslerinin neden 4,2 Milyar ile sınırlı olduğunu muhtemelen merak ediyorsunuzdur. DARPA'da ülkedeki mevcut (düzinelerce) ana bilgisayarları birbirine bağlamaya çalışırken birisi bu kararı verdi. Şimdi IPv4'ten IPv6'ya dönüştürüyoruz.
Kendine gel. Bu Berger King değil , istediğin gibi anlamıyorsun. Biri o zamanlar makul görünen bir karar verdi ve şimdi değil. Başa çıkmak.
ydrol, kutsal ya da her neyse, lütfen bana söyleyin - eğer biliyorsanız - static_cast mql4'te kullanılabilir mi! C++ ile aynı mı? Bu sayfa https://docs.mql4.com/basis/types/casting bundan hiç bahsetmiyor, forumlarda bulamıyorum, hiçbir yerde bulamıyorum. Kodlamamda sürekli olarak, yalnızca datetime'ı uzun süreye çevirmekle değil, aynı zamanda kaçınılmaz olduğu durumlarda da datetime'ı ikiye katlamakla ilgili durumlarla karşılaşıyorum, bu yüzden doğru yapmak istiyorum. Yani program, bir örneğin haftanın hangi bölümünde olduğunu bulur ve buna göre hesaplamalarında vurgular - ancak bir haftadaki saniye sayısı olan zaman modulo hala bir tarih saat tipi değişkendir ve başka bir şey olarak kullanamazsam, bu şekilde sıkışmış. Ama bunun matematiksel bir işlevini yerine getirmem ve sonunda bir çift olmam gerekiyor, görüyorsunuz. Bilmiyorsanız, üzülmeyin, ama lütfen bana bu tür durumlarda şeyleri nasıl düzgün bir şekilde yazmam gerektiğini söyleyin.
Dokümanlarda veri türleri ve typecasting ile ilgili bütün bir bölüm var, editörü kullanırken F1'e basıyor musunuz?
Aracınızın sunucusunun saat dilimidir. DÖNEM. mt4'ten aldığınız herhangi bir tarih, sunucunuzun saat dilimidir. ( TimeLocal() ve yeni mt5 TimeGMT hariç )
On yaşından büyük bir şeye mi şaşırdın? Y2K'yı hiç duydunuz mu? Değilse, tarihlerin neden yılda yalnızca iki basamakla saklandığına şaşıracaksınız, bu yüzden 1999'dan sonra 1900 veya 19100 yılıydı.
7 Milyarlık bir dünyada IP adreslerinin neden 4,2 Milyar ile sınırlı olduğunu muhtemelen merak ediyorsunuzdur. DARPA'da ülkedeki mevcut (düzinelerce) ana bilgisayarları birbirine bağlamaya çalışırken birisi bu kararı verdi. Şimdi IPv4'ten IPv6'ya dönüştürüyoruz.
Kendine gel. Bu Berger King değil , istediğin gibi anlamıyorsun. Biri o zamanlar makul görünen bir karar verdi ve şimdi değil. Başa çıkmak.
Aracınızın sunucusunun saat dilimidir. DÖNEM. mt4'ten aldığınız herhangi bir tarih, sunucunuzun saat dilimidir. ( TimeLocal() ve yeni mt5 TimeGMT hariç .
Bunu tekrar taramak, çünkü şu anda TimeZone/Session işlevlerimi düzenli bir mql4++ sınıfına taşıyorum!
WHRoeder: Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.
Bununla uğraşıyorum, ama hala neden ilk etapta zorunda olduğum konusunda şaşkınım! Saat dilimi bilgilerini yönetmeyle ilgili en iyi uygulamalar uzun süredir var. 1988'den beri. Örn. ISO 8601 için
ISO 8601'deki saat dilimleri , yerel saat (konum belirtilmemiş olarak), UTC olarak veya UTC'den bir fark olarak temsil edilir.
Bir zaman gösterimi ile UTC ilişki bilgisi verilmezse, saatin yerel saatte olduğu varsayılır. Aynı saat diliminde iletişim kurarken yerel saati varsaymak güvenli olsa da, farklı saat dilimleri arasında iletişimde kullanıldığında belirsizdir . "
Altı çizili kısım, daha fazla değilse bile, yaklaşık 30 yıldır BT'de biliniyor. MQL tarih saat formatı UnixTime'dan türetilmiştir (1/1/1970 sihirli tarihini havada çalmadılar), bu yüzden şimdi bunun farkında olmaları gerekirdi.
Yine 1988'de POSIX, UnixTime'ı onayladı
"POSIX komitesi, kütüphane işlevlerindeki karmaşıklığa karşı argümanlar tarafından yönlendirildi, ve Unix zamanını UTC zamanının unsurları açısından basit bir şekilde kesin olarak tanımladı. [Vurgum]
10 yıl önce istemci-sunucu sistemleri tasarlayan Sistem Mimarları veya geliştiriciler (ki bu o kadar uzun zaman önce değil), kritik zaman bilgisi alışverişinde bulunur, mevcut zaman dilimi karmaşasını tahmin etmek/önlemek için yeterli bilgiye sahip olmalıdır. Bir saat dilimindeki tüccarlar, bazen başka bir saat diliminde (örneğin NY) yorumlanmasını istedikleri verileri başka bir saat diliminde alırlar. Tek bahaneler:
- cehalet
- düşük öncelik (TZ karışıklığı tüccarlara değil, brokerlere fayda sağlar mı?)
- dışarıdan bizim için açık olmayan bazı teknik hususlar/kısıtlamalar/gereklilik. Belki çizelgeler falan çiziyorsun? Bilinen bir ofseti eklemek/çıkarmak o kadar zor olmasa da?
Daha önce de söylediğim gibi yukarıdakilerin hepsi beni şaşırtıyor. Geriye dönük test sırasında GMT zamanını hesaplamak için kod yazmam gerektiğini düşünmüyorum! Ancak TimeGMT() ve TimeLocal() doğru bir şekilde modellenmemiştir (her ikisi de geçmiş verilerden türetilen spesifik olmayan TZ'ye ayarlanmıştır), bu nedenle UTC'yi ve dolayısıyla Oturum başlangıç ve bitiş zamanlarını doğru bir şekilde hesaplamak için kendi saat dilimi işlevlerimizi kullanmamız gerekir. geri test sırasında.
PS WHRoeder tarafından "kendimi aşmam" söylenmesinin ironisi kaybolmadı :)