Bueno, no acabo de entender muy bien el problema.
Veamos. La base de datos está siempre, como dices, en formato epoch, por lo que podernos asumir que es UTC, aunque no lo es al 100%
Modificar el tiempo epoch, es fácil, le sumas a cada registro los segundos que correspondan, una o dos horas. Cambiar registros en SQL es sencillo.
Ahora bien, una cosa es que sea sencillo, y otra cosa es que cambiar una base de datos con miles, o decenas de miles de registros, y cada uno con un "offset" diferente, una o dos horas, no sea tarea de mucho, muchísimo tiempo.
Bueno, en realidad sólo hay que calcular el epoch de los cambios de hora y hacer cambios de registros selectivos.
Pero..... Es meterse en un berenjenal muy gordo
Por meteoclimatic no ese problema, o no lo es tanto
Y ello es porque a meteoclimatic, solo se le informa, en la plantilla de los datos actuales, diarios, mensuales y anuales
Por tanto, solo podría tener inconsistencias en el mes actual y en el año actual.
Nada que no podrías corregir fácilmente, pues estamos a mediados de mes y a primeros de año.
La verdad es que nunca me había planteado el problema. Desde el principio de los principios, siempre he manejado el día con formato UTC y todos mis ordenadores estén en formato UTC, salvo el mierda Windows.
Espero haberte ayudado.....a pesar de que no he dicho nada