Desarrolladores.Formato de tiempo en el terminal MT5 - página 5
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Para ello, el tipo datetime debería pasar a ser de 10 bytes, y la estructura MqlDateTime debería rejuvenecerse.
Vaya, te has dejado llevar :)
es suficiente. Son 8 bytes.Nadie habla de estructuras en absoluto. Todo debe permanecer como está ahora.
He leído el hilo y me he dado cuenta de que los milisegundos son necesarios sólo para un interés deportivo. Poder medir el precio de una carrera de 100 metros con una precisión de ms.
Para darlo, el tipo datetime debe convertirse en 10 bytes, y la estructura MqlDateTime debe ser gorda.
Espera a MQL6, el temporizador de milisegundos, el historial de ticks y otras cosas aparecerán allí. Pero no veo el sentido de añadirlo ahora. EN MI OPINIÓN.
Leer y comprender son cosas diferentes.
Pero gracias por calcular cuántos bytes ocupará MqlDateTime, afectará seriamente a mis 12 gigas, ya he visto el intercambio de MT5.
Sereyev ha dicho lo que creo que está claro desde el principio pero he olvidado en qué foro estoy. ¡Los milisegundos no son para la sincronización con el servidor, sino para entender la secuencia de eventos !
sergeev:
es suficiente. 8 bytes.
Sugerir más...
Cómo convertir el tiempo en tiempo y extraer los milisegundos.
Esto requerirá estructuras adicionales, tipos de datos y un par de tres nuevas funciones para convertir allí y de vuelta.
¿Por qué? cuando hay un datetime con una envoltura ya hecha.
Sugerir más...
Cómo convertir el tiempo en tiempo y extraer los milisegundos.
Esto requeriría estructuras adicionales, tipos de datos y un par de tres nuevas funciones para convertir de ida y vuelta.
¿Por qué? Cuando hay un datetime con una envoltura ya hecha.
Andrew, con todo respeto, pero no has pensado en tu respuesta.
El tiempo en milisegundos es el tiempo en segundos multiplicado por 1000 + el número de esos mismos ms.
total
Tomo el tiempo en milisegundos y lo divido por 1000 para obtener nuestro viejo datetime favorito con todas sus capacidades. MÁS el resto de la división: el número de milisegundos.
Eso es todo.
sergeev:
Tomo el tiempo en milisegundos, lo divido por 1000 y obtengo nuestra vieja fecha favorita con todas las posibilidades. MÁS el resto de la división es el número de milisegundos.
Entonces, para saber la hora, ¿tendré que dividir algo entre algo? ¿Y un error de redondeo? ¿Hay alguna forma de evitarlo sin dividirlo?
¿Así que tengo que dividir algo entre algo para saber la hora? ¿Qué pasa con el error de redondeo? ¿Hay alguna forma de evitarlo sin dividirlo?
pero los números son enteros :)
Si no quieres dividirlo, toma los tres últimos dígitos, son milisegundos.
Si no quieres dividir, simplemente toma los tres últimos dígitos, que son milisegundos.
¿Cómo los tomo sin dividirlos? ¿Convertir a una cadena y volver a convertir los tres caracteres de la derecha a un número entero? Eso no me inspira.
Y las operaciones adicionales de obtener el resto de la división, la multiplicación y otras operaciones para obtener milisegundos es una especie de salvajismo. EN MI OPINIÓN. Además, deberían estar disponibles en el mercado.
Me pregunto no eso, sino por qué originalmente los desarrolladores eligieron el formato UNIX para almacenar el tiempo, y no el que estamos hablando ahora, es decir, los milisegundos.
Deben saber algo.
Tipo de fecha:
Тип datetime предназначен для хранения даты и времени в виде количества секунд, прошедших с 01 января 1970 года. Занимает в памяти 8 байт.
Todo lo que tenías que hacer era hacerlo así:
El tipo datetime está diseñado para almacenar la fecha y la hora como el número de milisegundos transcurridos desde el 01 de enero de 1970. Ocupa 8 bytes de memoria.
¿Qué tiene que ver toda esta división y otras tonterías? El tiempo se puede almacenar en cualquier unidad (incluso en tertes). Se puede convertir en cualquier unidad (incluso las horas/segundos terrestres), incluso las marcianas. Esto no hará que la cantidad de recursos computacionales dedicados a la conversión sea menor o mayor. La conversión sólo es necesaria para la simple comprensión por parte del hombre, no de una máquina.
Tal vez decidieron ahorrar dinero y hacer más fuerte la compresión de las bases de datos históricas. Estimados desarrolladores, respondan por el bien de la historia, ¿por qué eligieron los segundos? Creo que simplemente consideraron innecesaria una mayor precisión, ya que incluso ahora no entienden por qué necesitan esos milisegundos.
Voy a verlo desde el otro lado.
1. Oferta = 1,30245 volumen de 50 lotes. Este nivel dura 30 ms.
2. Oferta = 1,30244 volumen 75 lotes. Este nivel dura 25 ms.
3. Oferta = 1,30243 volumen 300 lotes. Ha existido durante 2 segundos.
Esta información le ayudará en el comercio.
tal vez para los pipsizers sí ... pero ¿dónde está un corredor de este tipo que con cero retraso entrará en el mercado de sus 50 lotes?
¿Cómo los tomo sin dividirlos? ¿Convertir a una cadena y volver a convertir los tres caracteres de la derecha a un número entero? Eso no me inspira.
¿Te has preguntado alguna vez cómo se convierte la fecha en una estructura? ¿No es por la división y el resto?
¿o crees que funciona de forma diferente? http://msdn.microsoft.com/ru-RU/library/windows/desktop/ms724284%28v=vs.85%29.aspx
Deberían estar fácilmente disponibles, por lo demás.
bliiiiiin :) ¿pues qué tipo de ready-made? te han dado 8 bytes - ¿qué más necesitas de los desarrolladores?
Lo interesante no es eso, sino por qué los desarrolladores eligieron en un principio el formato UNIX para almacenar el tiempo y no el que ahora nos ocupa, es decir, los milisegundos.
Parece que sigues hablando de algún tipo de formato de tiempo. OK. ¿Cuáles conoces?
Conozco personalmente a 3.
- 4 bytes - el número de segundos desde la era unix 1970 hasta 2038 (INT)
- 8 bytes - número de 100 nanosegundos de 1601 a 30828 (FILETIME)
- 8 bytes - número de milisegundos desde 1970 unix epoch hasta 2038 (INT64)
también hay una estructura de almacenamiento de tiempo de 8 bytes SYSTEMTIME, pero es derivada. etc.
Lo que estoy sugiriendo es que demos lo que ya tenemos en el servidor MT - 8 bytes de la era unix.
¿qué ocultar? :)