Beim Versuch eine nachhaltige Lösung über das Y2k38-Problem hinaus zu schreiben,
bin ich grade vom Regen in die Traufe gekommen.
Erstmal scheint Maria-DB das Problem noch nicht angegangen zu sein, denn während es bei Mysql gehen sollte
MySQL :: MySQL 8.0 Reference Manual :: 12.7 Date and Time Functions
Prior to MySQL 8.0.28, the valid range of argument values is the same as for the TIMESTAMP data type: '1970-01-01 00:00:01.000000' UTC to '2038-01-19 03:14:07.999999' UTC. This is also the case in MySQL 8.0.28 and later for 32-bit platforms. For MySQL 8.0.28 and later running on 64-bit platforms, the valid range of argument values for UNIX_TIMESTAMP() is '1970-01-01 00:00:01.000000' UTC to '3001-01-19 03:14:07.999999' UTC (corresponding to 32536771199.999999 seconds).
steht bei Maria:
UNIX_TIMESTAMP
Timestamps in MariaDB have a maximum value of 2147483647, equivalent to 2038-01-19 05:14:07. This is due to the underlying 32-bit limitation. Using the function on a date beyond this will result in NULL being returned. Use DATETIME as a storage type if you require dates beyond this.
Und siehe da:
SELECT UNIX_TIMESTAMP('2038-01-19');
+------------------------------+
| UNIX_TIMESTAMP('2038-01-19') |
+------------------------------+
| 2147468400 |
+------------------------------+
SELECT UNIX_TIMESTAMP('2038-01-20');
+------------------------------+
| UNIX_TIMESTAMP('2038-01-20') |
+------------------------------+
| NULL |
+------------------------------+
Bei einem Projekt werden ungefähr minütlich Messwerte geschrieben.
Ich wollte mir mit TIMESTAMPDIFF(SECOND, '1970-01-01 00:00:00', utc_time()) helfen.
Das führte zu dem verwirrenden Ergebnis, dass nachts zwischen 0 und 2 Uhr werden Messwerte für den NÄCHSTEN Tag geschrieben werden !!??
Sieht so aus:
INSERT IGNORE INTO messwerte
VALUES ( TIMESTAMPDIFF(SECOND, '1970-01-01 00:00:00', utc_time()), #messwert# )';
Ergebnis:
SELECT *,from_unixtime(time) FROM messwerte
WHERE timestamp between '2023-08-15 01:58' and '2023-08-15 02:02'
ORDER id;
+--------+------------+--------+---------------------+---------------------+
| id | time | value | timestamp | from_unixtime(time) |
+--------+------------+--------+---------------------+---------------------+
| 314674 | 1692143913 | 19.875 | 2023-08-15 01:58:33 | 2023-08-16 01:58:33 |
| 314675 | 1692143975 | 19.937 | 2023-08-15 01:59:35 | 2023-08-16 01:59:35 |
| 314676 | 1692057633 | 20 | 2023-08-15 02:00:33 | 2023-08-15 02:00:33 |
| 314677 | 1692057694 | 20 | 2023-08-15 02:01:34 | 2023-08-15 02:01:34 |
+--------+------------+--------+---------------------+---------------------+
Wie man sieht, sind die automatisch geschriebenen id und timestamp (auto_increment und current_timestamp) fortlaufend,
während der TIMESTAMPDIFF in Verbindung mit utc_time mal schnell einen Hüpfer von 24h macht.
Ich kann mir den Grund irgendwie zusammenreimen,
auch wenn es verwirrend bleibt:
Da ich nur utc_time ohne datum genommen habe, will Maria mir helfen und denkt sich ein Datum dazu aus.
Dabei wird das dazugedichtete Datum nicht von utc sondern von der lokalisierten Rechnerzeit genommen.
Und da bei uns schon der 15te war (z.B.2023-08-15 01:59:35 MEST)
bei UTC aber noch der 14te (Beim Beispiel vermutlich 2023-08-14 23:59:23 UTC).
Ergibt sich ein Datum in der Zukunft.
Also MEST-DATE + UTC-TIME 2023-08-15 23:59:23
Wenn das als UTC-DATETIME interpretiert wird,
dann ergibt das 2023-08-16 01:59:35 MEST.
..sehr verwirrend.
Die Suche hat sich noch dadurch erschwert, dass bei
SELECT
TIMESTAMPDIFF(SECOND, '1970-01-01 00:00:00', '07:00:00');
+----------------------------------------------------------+
| TIMESTAMPDIFF(SECOND, '1970-01-01 00:00:00', '07:00:00') |
+----------------------------------------------------------+
| NULL |
+----------------------------------------------------------+
KEIN DATUM dazu erfunden wird.
Bei
SELECT TIMESTAMPDIFF(SECOND, '1970-01-01 00:00:00', utc_time());
+----------------------------------------------------------+
| TIMESTAMPDIFF(SECOND, '1970-01-01 00:00:00', utc_time()) |
+----------------------------------------------------------+
| 1692096234 |
+----------------------------------------------------------+
aber schon.
..nur eben nicht das richtige..
bin ich grade vom Regen in die Traufe gekommen.
Erstmal scheint Maria-DB das Problem noch nicht angegangen zu sein, denn während es bei Mysql gehen sollte
MySQL :: MySQL 8.0 Reference Manual :: 12.7 Date and Time Functions
Prior to MySQL 8.0.28, the valid range of argument values is the same as for the TIMESTAMP data type: '1970-01-01 00:00:01.000000' UTC to '2038-01-19 03:14:07.999999' UTC. This is also the case in MySQL 8.0.28 and later for 32-bit platforms. For MySQL 8.0.28 and later running on 64-bit platforms, the valid range of argument values for UNIX_TIMESTAMP() is '1970-01-01 00:00:01.000000' UTC to '3001-01-19 03:14:07.999999' UTC (corresponding to 32536771199.999999 seconds).
steht bei Maria:
UNIX_TIMESTAMP
Timestamps in MariaDB have a maximum value of 2147483647, equivalent to 2038-01-19 05:14:07. This is due to the underlying 32-bit limitation. Using the function on a date beyond this will result in NULL being returned. Use DATETIME as a storage type if you require dates beyond this.
Und siehe da:
SELECT UNIX_TIMESTAMP('2038-01-19');
+------------------------------+
| UNIX_TIMESTAMP('2038-01-19') |
+------------------------------+
| 2147468400 |
+------------------------------+
SELECT UNIX_TIMESTAMP('2038-01-20');
+------------------------------+
| UNIX_TIMESTAMP('2038-01-20') |
+------------------------------+
| NULL |
+------------------------------+
Bei einem Projekt werden ungefähr minütlich Messwerte geschrieben.
Ich wollte mir mit TIMESTAMPDIFF(SECOND, '1970-01-01 00:00:00', utc_time()) helfen.
Das führte zu dem verwirrenden Ergebnis, dass nachts zwischen 0 und 2 Uhr werden Messwerte für den NÄCHSTEN Tag geschrieben werden !!??
Sieht so aus:
INSERT IGNORE INTO messwerte
VALUES ( TIMESTAMPDIFF(SECOND, '1970-01-01 00:00:00', utc_time()), #messwert# )';
Ergebnis:
SELECT *,from_unixtime(time) FROM messwerte
WHERE timestamp between '2023-08-15 01:58' and '2023-08-15 02:02'
ORDER id;
+--------+------------+--------+---------------------+---------------------+
| id | time | value | timestamp | from_unixtime(time) |
+--------+------------+--------+---------------------+---------------------+
| 314674 | 1692143913 | 19.875 | 2023-08-15 01:58:33 | 2023-08-16 01:58:33 |
| 314675 | 1692143975 | 19.937 | 2023-08-15 01:59:35 | 2023-08-16 01:59:35 |
| 314676 | 1692057633 | 20 | 2023-08-15 02:00:33 | 2023-08-15 02:00:33 |
| 314677 | 1692057694 | 20 | 2023-08-15 02:01:34 | 2023-08-15 02:01:34 |
+--------+------------+--------+---------------------+---------------------+
Wie man sieht, sind die automatisch geschriebenen id und timestamp (auto_increment und current_timestamp) fortlaufend,
während der TIMESTAMPDIFF in Verbindung mit utc_time mal schnell einen Hüpfer von 24h macht.
Ich kann mir den Grund irgendwie zusammenreimen,
auch wenn es verwirrend bleibt:
Da ich nur utc_time ohne datum genommen habe, will Maria mir helfen und denkt sich ein Datum dazu aus.
Dabei wird das dazugedichtete Datum nicht von utc sondern von der lokalisierten Rechnerzeit genommen.
Und da bei uns schon der 15te war (z.B.2023-08-15 01:59:35 MEST)
bei UTC aber noch der 14te (Beim Beispiel vermutlich 2023-08-14 23:59:23 UTC).
Ergibt sich ein Datum in der Zukunft.
Also MEST-DATE + UTC-TIME 2023-08-15 23:59:23
Wenn das als UTC-DATETIME interpretiert wird,
dann ergibt das 2023-08-16 01:59:35 MEST.
..sehr verwirrend.
Die Suche hat sich noch dadurch erschwert, dass bei
SELECT
TIMESTAMPDIFF(SECOND, '1970-01-01 00:00:00', '07:00:00');
+----------------------------------------------------------+
| TIMESTAMPDIFF(SECOND, '1970-01-01 00:00:00', '07:00:00') |
+----------------------------------------------------------+
| NULL |
+----------------------------------------------------------+
KEIN DATUM dazu erfunden wird.
Bei
SELECT TIMESTAMPDIFF(SECOND, '1970-01-01 00:00:00', utc_time());
+----------------------------------------------------------+
| TIMESTAMPDIFF(SECOND, '1970-01-01 00:00:00', utc_time()) |
+----------------------------------------------------------+
| 1692096234 |
+----------------------------------------------------------+
aber schon.
..nur eben nicht das richtige..
