Autor Tema: Minimizar la pérdida de datos del último cuarto de hora del día  (Leído 38155 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado jmviper

  • Investigación
  • Hero Member
  • ******
  • Mensajes: 4.403
  • "Vortex Complex"
    • Ver Perfil
    • www.meteoarchena.es
  • Estación: Archena - ESMUR3000000030600B
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #60 en: 21 de Octubre del 2016, 13:23:56 pm »
No Amon-K, para mí no es árido el tema y está bastante claro... cualquier programa resetea valores a las 0:00 excepto por lo que estoy viendo weewx. Tanto WD como Cumulus resetean las máx/mín a las 0:00 ya que las 0:00 es hora del nuevo día y si no es así como has expuesto con tu reducción al absurdo me compraré un nuevo reloj o PC que a las 0:00:00 no cambie la fecha (si encuentras algún sistema que a las 0:00:00 no cambie la fecha me lo dices  ::)).

No creo que sea cuestión de decirles a Brian (WD) y a Steve (Cumulus) que consideren las 0:00 como todavía del día anterior y no reseteen las máx/mín en ese instante y lo hagan 1 segundo o 1 minuto después...

WD tiene muchas cosas (muchas con bugs  ::)) pero por ejemplo en la creación de plantillas puedes poner las horas personalizadas en vez de hacerlo cada intervalo de tiempo. Y por supuesto que he probado a resetear a las 0:00 las máx/mín y salían las de las 0:00 y no las del día anterior por eso hice lo de que WD me generase la última plantilla a las 23:59 y no perder ningún dato del día (excepto si por casualidad se produce entre las 23:59 y las 0:00).


Creo que no lo he explicado suficientemente. Yo no le he puesto nada a la plantilla de las 00:00, weewx ha enviado la realidad, 12,6mm caídos hasta las 23:50 más 0,4mm caídos entre las 23:50 y las 00:00 son los 13mm enviados.


No he dicho que tú lo hayas puesto adrede y también me expresé yo mal  ;D. Si la plantilla en el nuevo día pone 13 mm él interpreta que han caído 13 mm y "guarda" lo que recibió en la última plantilla con fecha del día de ayer (en este caso 12.6 mm) y lo suma y si encuentra 0.4 mm en la plantilla también se los suma a los 12.6 mm.

Yo por mi parte no voy a darle vueltas al tema más ni voy a buscar reducciones al absurdo  ;D ya que lo tengo meridianamente claro. Si weewx hace lo que tú dices no por ello van a hacer los demás programas lo mismo o hay que cambiar todo el sistema para que lo interprete para tu plantilla.

Es lo que hay y cada uno busca sus mañas para intentar no perder datos en el cambio de día.

Saludos
« Última modificación: 21 de Octubre del 2016, 13:58:47 pm por jmviper »


Archena, Valle de Ricote (Murcia). 120 msnm. 19.622 hab.
Davis Vantage Pro2 Plus

www.meteoarchena.es

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #61 en: 22 de Octubre del 2016, 01:48:33 am »
Buenas noches jmviper.

Creo que tienes razón y muchas veces hago extensiva mi visión parcial, ya que desconozco en profundidad otro software que no sea Weewx.


No Amon-K, para mí no es árido el tema y está bastante claro... cualquier programa resetea valores a las 0:00 excepto por lo que estoy viendo weewx. Tanto WD como Cumulus resetean las máx/mín a las 0:00 ya que las 0:00 es hora del nuevo día y si no es así como has expuesto con tu reducción al absurdo me compraré un nuevo reloj o PC que a las 0:00:00 no cambie la fecha (si encuentras algún sistema que a las 0:00:00 no cambie la fecha me lo dices  ::)).

Cuando hablaba que era un tema árido lo hacía pensando en que era poco atractivo.
Weewx también resetea a las 00:00 pero antes guarda los datos de ese momento, porque son muy importantes, de hecho toda esta conversación tiene como objetivo no perderlos. Yo también creo que a las 00:00 cambia la fecha, pero lo hace porque las 00:00 es el final del minuto 60 de la última hora del día que termina y coincide que también es el principio del minuto 1 de la primera hora del día que empieza, con todas esas coincidencias es normal que cambie la fecha. Y hago hincapié, las 00:00 es las dos cosas y no solamente la segunda.


WD tiene muchas cosas (muchas con bugs  ::)) pero por ejemplo en la creación de plantillas puedes poner las horas personalizadas en vez de hacerlo cada intervalo de tiempo. Y por supuesto que he probado a resetear a las 0:00 las máx/mín y salían las de las 0:00 y no las del día anterior por eso hice lo de que WD me generase la última plantilla a las 23:59 y no perder ningún dato del día (excepto si por casualidad se produce entre las 23:59 y las 0:00).

Aquí me parece que he supuesto que WD funciona de manera similar a Weewx y según parece no es así. Puedo suponer ahora que cuando WD genera la plantilla lo hace leyendo los datos actuales de la Estación y los incluye en la misma. Es verdad, de esa manera solo se perderían los datos del último minuto.
También en WD se puede configurar el momento en el que se resetean los datos. Si quiero leer los datos de las 00:00 no tendré que resetear en ese momento, sino despues, por ejemplo a las 00:01. Quizás, y recalco quizás, entonces podría estar en la plantilla generada a las 00:00 los datos que buscamos y que se pierden.   

No he dicho que tú lo hayas puesto adrede y también me expresé yo mal  ;D. Si la plantilla en el nuevo día pone 13 mm él interpreta que han caído 13 mm y "guarda" lo que recibió en la última plantilla con fecha del día de ayer (en este caso 12.6 mm) y lo suma y si encuentra 0.4 mm en la plantilla también se los suma a los 12.6 mm.

Si, todo eso hace, pero ¿es lógico que?:
1º A las 00:00 de un día que está comenzando, aparezca que ya han caído 13mm. (13mm en 0 segundos, intensidad de lluvia infinita)
2º A las 00:00 aparezca que el Episodio Precipitación sean 25,6mm cuando solo han caído hasta ese momento 13mm.
3º En el día anterior ponga que han caído 12,6mm cuando han caído 13mm.
No, no es lógico.

Yo por mi parte no voy a darle vueltas al tema más ni voy a buscar reducciones al absurdo  ;D ya que lo tengo meridianamente claro. Si weewx hace lo que tú dices no por ello van a hacer los demás programas lo mismo o hay que cambiar todo el sistema para que lo interprete para tu plantilla.

Es verdad, reconozco mi error. No todos los programas tienen que poder hacer lo que yo diga o piense como lógico para conseguir no perder los datos definitivos del día, los del final, pero creo que a todos nos gustaría que no se perdieran. Yo lo estoy intentando. Perdoname por mi insistencia.

Saludos.
« Última modificación: 22 de Octubre del 2016, 01:52:59 am por Amon-K »
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado jmviper

  • Investigación
  • Hero Member
  • ******
  • Mensajes: 4.403
  • "Vortex Complex"
    • Ver Perfil
    • www.meteoarchena.es
  • Estación: Archena - ESMUR3000000030600B
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #62 en: 22 de Octubre del 2016, 10:17:11 am »
Desde luego Amon-K se nota que tienes una mente inquieta  ;D ;D

Te voy a ir puntualizando aunque yo tenga también visión parcial...

Buenas noches jmviper.

Creo que tienes razón y muchas veces hago extensiva mi visión parcial, ya que desconozco en profundidad otro software que no sea Weewx.

Yo también creo que a las 00:00 cambia la fecha, pero lo hace porque las 00:00 es el final del minuto 60 de la última hora del día que termina y coincide que también es el principio del minuto 1 de la primera hora del día que empieza, con todas esas coincidencias es normal que cambie la fecha. Y hago hincapié, las 00:00 es las dos cosas y no solamente la segunda.


Aquí podríamos debatir sobre el famoso caso de qué es primero el huevo o la gallina....

Te explico...

Cuando pones el cronómetro en tu móvil o en un reloj qué tiempo pone?? 0:00:00.000 (si pone milésimas claro) y ... eso no es el final de nada ... es el principio de algo en este caso la cuenta y en el caso que nos ocupa las 0:00:00 no es el final del día anterior sino el principio del día siguiente sencillamente porque en ese instante cambia la fecha y no pertenece ya al día anterior mires por donde lo mires.

Si por ejemplo meteoclimatic ve que en la plantilla pone por ejemplo "día 12" y lee también "13 mm" interpreta que ese día han caído 13 mm independientemente de si son las 0:00 o las 0:01 o las 3:00.

Si weewex manda una plantilla con el día siguiente "día 13" con hora 0:00 y pone "13 mm" crees que debe interpretar meteoclimatic que son del día 12 ?? Pues no, interpreta lo que es que son del día 13.

Programando se puede hacer de todo hasta considerar que el instante 0:00:00 es del día anterior pero creo que no es lo lógico por lo que ya he expuesto anteriormente (que el instante 0:00:00 no pertenece al día anterior).


También en WD se puede configurar el momento en el que se resetean los datos. Si quiero leer los datos de las 00:00 no tendré que resetear en ese momento, sino despues, por ejemplo a las 00:01. Quizás, y recalco quizás, entonces podría estar en la plantilla generada a las 00:00 los datos que buscamos y que se pierden.   


WD no hila tan fino... puedes poner cualquier hora sí pero es hora en punto. No admite minutos.

Lo dicho antes. Cada uno con las características de su programa que haga lo que mejor pueda para no perder datos.

Saludos



Archena, Valle de Ricote (Murcia). 120 msnm. 19.622 hab.
Davis Vantage Pro2 Plus

www.meteoarchena.es

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #63 en: 23 de Octubre del 2016, 03:37:34 am »
Buenas noches jmviper.



Cuando pones el cronómetro en tu móvil o en un reloj qué tiempo pone?? 0:00:00.000 (si pone milésimas claro) y ... eso no es el final de nada ... es el principio de algo en este caso la cuenta y en el caso que nos ocupa las 0:00:00 no es el final del día anterior sino el principio del día siguiente sencillamente porque en ese instante cambia la fecha y no pertenece ya al día anterior mires por donde lo mires.

El ejemplo del cronómetro no es comparable con nuestra disquisición. Antes del comienzo de la cuenta del cronómetro no hay nada. Antes del comienzo de un dia hay otro y sin parar.

Siempre me dices que las 00:00 no es el final del día anterior pero nunca me dices donde está. ¿Existe?. Me gustaría que me dieras tu visión razonadamente. Voy a empezar yo a darla.

Vamos a empezar el razonamiento desde el principio.

Creo que podemos estar de acuerdo en que cada día tiene un principio y un final (y en medio, su afán como dice un refrán  ;) ;)).

También podemos estar de acuerdo en que el final de un día tendrá que llegar no despues de que comience el siguiente porque en ese caso habría algunos momentos en que no sabríamos en qué día estamos, y sabemos que esto no le ocurre a las personas normales. Es decir solo existen dos posibilidades o llega antes o al mismo tiempo.

Si llegara antes, ¿en medio que hay?, ¿un minuto?, ¿un segundo?, ¿alguna otra cosa?. Si hubiera un segundo o un minuto al hablar de una semana diríamos: son siete días y siete segundos, o son siete días y siete minutos y así no lo expresamos hasta ahora, luego esta opción no parece verosímil. Si hubiera alguna otra cosa, ¿no lo habríamos descubierto?, ¿no habría equipos de investigación trabajando en ello?, tendríamos que decir al referirnos a una semana, son siete días y siete algunas otras cosas. Yo no he oído nunca nada parecido, luego tampoco me parece verosímil, y por otro otro lado quien hubiese organizado la medida del tiempo de esta manera habría sido un torpe.

Luego, por reducción al absurdo (ya sé que no te gusta mucho esta forma de razonar pero es tan válida como cualquier otra), solo queda una opción: que coincidan.

En términos numéricos y de medida del tiempo, y un poco más en serio, podríamos expresarlo de la siguiente manera:

22/10/2016 23:59:60 = 23/10/2016 00:00:00

La primera parte de la igualdad representa el día 22 de Octubre de 2016 en la hora 23 y 59 minutos y 60 segundos, es decir el final del día 22. La segunda parte de la igualdad es el día 23 de Octubre de 2016 a la 0 horas y 0 minutos y 0 segundos, es decir el comienzo del dia 23. Si hacemos las operaciones necesarias en el primer término obtenemos el segundo, ambas términos son por tanto iguales,  es decir son el mismo momento, coinciden. Observa también que cambia la fecha en ese momento.

Si despues de saber donde está para tí el final de un día nos ponemos de acuerdo, quizás podamos avanzar, ¿no crees?.

Saludos.
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado B.Santiago

  • Moderador Global
  • Hero Member
  • ******
  • Mensajes: 1.979
    • Ver Perfil
  • Estación: Ávila- La Colilla [ESCYL0500000005192A]
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #64 en: 23 de Octubre del 2016, 09:28:08 am »
La respuesta 41 en este hilo  tiene las claves.
Sea magnitud física ponderable, sea dimensión añadible a las demás, las divisiones del tiempo son convencionales.
En este aspecto, Meteoclimatic se atiene a convenciones admitidas universalmente.
O casi.
Otras redes funcionan de otra manera, y tal vez compartimenten el tiempo "mejor" de lo que se hace aquí, y recojan sin pérdida alguna  los datos que obtienen,a la perfección.
Si este es el momento en que hay que reconocer que aquí se pierden ínfimas, irrelevantes cantidades de datos, unas pocas veces al año, en unas pocas estaciones en las que puedan darse  determinadas circunstancias de lluvia, se hace sin que nos duelan prendas.
   
Ya hemos llegado a un punto de bizantinismo insomne, que en mi opinión hace inútil y superflua cualquier  intervención posterior a esta.
 Meteoclimatic funciona como debe, quizá de modo imperfecto, y desde luego perfectible como cualquier obra humana.
Son las lentejas que hay. No se van a cambiar a gusto de uno ( ¿de cada uno?) de los usuarios.
Por mi parte, considero suficientemente debatido el asunto, e irresoluble hoy por hoy,  y no intervendré más.
[img width=180

Desconectado jantoni

  • Hero Member
  • *****
  • Mensajes: 3.754
    • Ver Perfil
  • Estación: ESMAD2800000028522A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #65 en: 23 de Octubre del 2016, 10:17:34 am »
Por cerrar el debate.

Ya lo dije al principio.

El trabajo de Amon-K me parece encomiable, pero llega un momento que no puedes avanzar más, por la propia tecnología de Meteoclimatic.

Posiblemente, en un futuro próximo, la actualización, en lugar de cada 15 minutos, será cada 5 minutos.

Pero el tema debe cerrarse. Meteoclimatic no puede cambiar todo el código, por la sencilla razón que tendría que convertirse en un sistema en tiempo real absoluto para 2000 usuarios, y eso es imposible ahora.

Saludos.

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #66 en: 23 de Octubre del 2016, 13:28:55 pm »
Teneis razon.

Ya jmviper me hizo ver que el tema no tenía mucho recorrido pero a veces la corriente te arrastra al lugar no deseado, intentando hacer ver aquello que te gustaría que los demás vieran.

Pido vuestra comprensión. No insistiré más. Por mi parte tema cerrado.

Saludos.
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado alcion

  • Newbie
  • *
  • Mensajes: 37
    • Ver Perfil
    • Utrera 'La Mulata'
  • Estación: Utrera - La Mulata (ESAND4100000041710C)
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #67 en: 31 de Octubre del 2016, 11:04:19 am »
El tema de la pérdida de datos en los últimos minutos del día se solucionaría añadiendo de forma rutinaria el resumen del día anterior, igual que se incluye el resumen del día en curso, del mes en curso y del año en curso.
Que habría que cambiar cosas en los scripts de Meteoclimatic: Seguro. Pero no hay nada que no tenga solución.

Un saludo.
Meteo Utrera-La Mulata

PCE-FWS20 + weewx + RaspberryPi


Desconectado B.Santiago

  • Moderador Global
  • Hero Member
  • ******
  • Mensajes: 1.979
    • Ver Perfil
  • Estación: Ávila- La Colilla [ESCYL0500000005192A]
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #68 en: 31 de Octubre del 2016, 14:16:22 pm »
El calendario y los mapas resuelven eso.
[img width=180

Desconectado Amon-K

  • Full Member
  • ***
  • Mensajes: 208
    • Ver Perfil
    • MeteoPG
  • Estación: Puente Genil - ESAND1400000014500A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #69 en: 01 de Noviembre del 2016, 03:25:20 am »
El tema de la pérdida de datos en los últimos minutos del día se solucionaría añadiendo de forma rutinaria el resumen del día anterior, igual que se incluye el resumen del día en curso, del mes en curso y del año en curso.
Que habría que cambiar cosas en los scripts de Meteoclimatic: Seguro. Pero no hay nada que no tenga solución.
Tienes razon Alcion, es como enviar durante 24 horas lo que yo quería enviar fugazmente.
No hay nada que no tenga solución,  y muchas veces más de una.

El calendario y los mapas resuelven eso.
Al consultar los datos atrasados podríamos estar viendo datos erroneos, si coincide con uno de esos días y el observador de la Estación aún no los hubiese corregido manualmente.

Saludos.
  ESAND1400000014500A http://meteopg.ddns.net Davis VP2 + Raspberry Pi 2 + Weewx 3.7.1

Desconectado B.Santiago

  • Moderador Global
  • Hero Member
  • ******
  • Mensajes: 1.979
    • Ver Perfil
  • Estación: Ávila- La Colilla [ESCYL0500000005192A]
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #70 en: 01 de Noviembre del 2016, 10:12:41 am »
Podríamos.
Si coincide...

Respondí literalmente a lo que solicitaba alcion: indicando como puede consultarse el resumen del día anterior.
[img width=180

Desconectado alcion

  • Newbie
  • *
  • Mensajes: 37
    • Ver Perfil
    • Utrera 'La Mulata'
  • Estación: Utrera - La Mulata (ESAND4100000041710C)
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #71 en: 02 de Noviembre del 2016, 13:27:50 pm »
Podríamos.
Si coincide...

Respondí literalmente a lo que solicitaba alcion: indicando como puede consultarse el resumen del día anterior.

No estaba preguntando como ver el día anterior.
Si el día anterior está mal se verá mal a menos que el dueño de la estación lo haya subsanado.
Lo que quería decir es que una forma de arreglar el problema de la falta de datos cerca del cambio de fecha sería subir el resumen del día anterior, de la misma forma que se suben los resúmenes del día en curso, del mes en curso y del año en curso.
Meteo Utrera-La Mulata

PCE-FWS20 + weewx + RaspberryPi


Desconectado B.Santiago

  • Moderador Global
  • Hero Member
  • ******
  • Mensajes: 1.979
    • Ver Perfil
  • Estación: Ávila- La Colilla [ESCYL0500000005192A]
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #72 en: 02 de Noviembre del 2016, 15:58:37 pm »
 ¡Vuelta la burra al trigo!
Claro que el post de alcion no planteaba ninguna pregunta.
Era, por mi parte, una torpe manera de explicar a qué me refería cuando escribí lo de los mapas y el calendario.
El resumen del día anterior es perfectamente accesible, de forma rutinaria, desde siempre,  como sabemos.
Que esté bien o mal...  Que los datos sean perfectos, exactos,  corregidos o no...

Se  añade de forma rutinaria, cómo cree alcion que debería hacerse.
Aunque tal vez yo no lo comprenda, y alcion  quiera ver por duplicado el resumen del día anterior: donde ya está y también en la ficha mis estaciones...
« Última modificación: 02 de Noviembre del 2016, 16:02:31 pm por B.Santiago »
[img width=180

Desconectado Ubik

  • Administrator
  • Hero Member
  • ******
  • Mensajes: 1.995
    • Ver Perfil
  • Estación: Villavieja de Yeltes ESCYL3700000037260A
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #73 en: 02 de Noviembre del 2016, 16:08:51 pm »
No he querido intervenir en este debate, porque la verdad es que me parece que no "ha lugar". Lo dije al principio y lo repito, con enviar lo más tarde posible se soluciona en gran medida el problema.

Queda claro, el último momento, pero eso es algo que a muchos nos da lo mismo, ya que los que corregimos los datos de lluvia con pluviómetro manual vamos a revisar los datos todos los días, o al menos aquellos en los que llueva.

En definitiva, está muy bien lo que proponéis, pero todo lo que hay que supone  a nivel de cambio de código, aumento del tamaño de la base de datos, cambio de plantilla, . . . cuando lo único que hay que hacer es estar pendientes cada uno de su estación durante 5 minutos al mes no sé si realmente compensa.

Está claro, que para el que no se preocupa de corregir inconsistencias, esto sería cojonudo, menos trabajo, pero para los que estamos pendientes de nuestras estaciones, la verdad es que con comprobar el informe de nuestro programa y comparar es suficiente y por lo tanto nos da los mismo que durante unas horas fallen unas décimas en una medida, por la mañana ya las hemos corregido.

Supongo que este problema también ocurre en otras redes. Imagino que habrá que proponer el mismo cambio a todas, . . . a no, que las otras no tienen inconsistencias.

Podemos abrir otro hilo para discutir sobre el sexo de los ángeles, . .  pero nos va a dar lo mismo, tendrán el que quieran, eso sí nos habremos entretenido.

Que aunque alguno crea que es un offtopic, pienso que no, porque con el movimiento de las alas de alguna manera afectarán a la circulación del aire. .. . . . . . en fin

 
« Última modificación: 02 de Noviembre del 2016, 16:12:17 pm por Ubik »
                         
Davis pro2+cumulus+W7+Lenovo
 
Web http://www.meteovillavieja.es

Desconectado B.Santiago

  • Moderador Global
  • Hero Member
  • ******
  • Mensajes: 1.979
    • Ver Perfil
  • Estación: Ávila- La Colilla [ESCYL0500000005192A]
Re:Minimizar la pérdida de datos del último cuarto de hora del día
« Respuesta #74 en: 02 de Noviembre del 2016, 16:22:02 pm »
Ni tienen inconsistencias que señalar al usuario, ni guardan y ofrecen valores extremos de un vistazo,  ni te ofrecen el resumen de cualquier día del año en dos clicks...
Por citar una donde es fácil encontrar esas características, citaré PWS. Pero no las ofrece al primer golpe de vista. Y desde luego no repara en inconsistencias.
Cada red tiene sus características e imperfecciones, pero el rigor y la exigencia de calidad que requiere Meteoclimatic no son comparables con los de ninguna otra. Que yo conozca.
Por supuesto que hay fallos y aspectos muy mejorables
Se lleva un par de años,  o más bien tres, trabajando en una nueva versión de la web, y un día estará disponible, sin duda, pero se hace cuando es posible, lo que significa que más despacio de lo que a muchos nos gustaría.
Quizá la nueva versión web solucione algunas de estas pequeñas cosas. Habrá que esperar, y mientras tanto soportar esa minucia ( a mí me lo parece) a riesgo de que algunos de los miembros de Meteoclimatic lamenten su existencia.
« Última modificación: 02 de Noviembre del 2016, 16:41:13 pm por B.Santiago »
[img width=180