Forstår ikke fejlen "Incorrect datetime value"

Jeg kan lige supplere med, at jeg har testet med følgende timestamps:
2023-03-26 02:00:00 = fejl
2023-03-26 02:59:59 = fejl (59m,59s senere)
2023-03-26 03:00:00 = virker (1 time senere)
2023-03-27 02:00:00 = virker (1 døgn senere)
2023-03-25 02:00:00 = virker (1 døgn tidligere)
2023-03-26 01:59:59 = virker (1 sek.tidligere)
2024-03-26 02:00:00 = virker (1 år senere)

Men jeg opdager nu, at den time, hvor det giver fejl, er tidspunktet for sommertid i 2023. Det er givet vis, det som er problemet.

Er der et trick til at ignorere det? Fakta er jo, at det pågældende tidspunkt jo eksisterer i DB i forvejen.

De tider bør ikke eksistere i databasen.

Klokken skifter fra 01:59:59 til 03:00:00. Og det giver ingen mening at have et tidspunkt i databasen som ikke eksisterer i virkeligheden.

Men hvad gør du praktisk?

Det er upraktisk at finde de tidspunkter og lægge en time til.

Sætte tidzzone til en uden sommertid kan have masser af bivirkninger.

Hvad gør de kendte dump og load programmer i dette tilfælde?

Egentligt burde vi have uret til at køreren ren GMT tid og så et præsentations lag over - der justerer med 1 time eller 2 for DK.

Der er også det andet problem om efteråret - hvor uret stilles tilbage og en sortering på tid så ikke er kronologisk. Specielt det var vores Unisys mainframe folk så ræd for at de lukkede ned den time.

Vi Oracle folk lod databaserne køre,  tanken om at lukke mange servere og databaser på samme tid syntes vi ikke om - hvis de har kørt længe er der nok ikke alle der kommer pænt op. Og skulle vi få brug for en restore måtte vi styre den på den besværlige måde på transaktionsnummer og ikke tid.

Vi har lidt det same problem  med dualboot på Windows -de går begge ind og justerer en time på uret - igen ren GMT tid på uret og et præsentationslag i styresystemet ville være at foretrække.  Jeg mener visse unix systemer gør det på den måde.

@kurt54

MySQL kan begge.

DATETIME er gemt som et antal heltal med de forskellige komponenter.

TIMESTAMP er gemt som antal sekunder siden epoch (UTC).

@kurt54

Unisys som i OS/1100 eller OS/2200?

@arne_v

OS/1100 og muligvis også OS/2200 - firserne og frem..

@kurt54

Jeg troede faktisk ikke at der var sådan nogle tilbage i Danmark.

Men jeg kender ikke det markede (ikke-IBM-kompatibel mainframe) specielt godt.

Den eneste sådan maskine jeg kender til var RECKU's.

@arne_v

Frem var forkert valgt - mente slet ikke til nu.
RECKU,s kender jeg vist, hvis det var den der en overgang stod på HCØ. DSB, HK og SAS var de firmaer jeg kendte der brugte Unisys mainframe.

Jeg kan se, at typen “timestamp” er en fejl. Det får jeg lige rettet til “datetime”, men det løser formentligt ikke problemet.
Og jeg kan godt se, at jeg har en fejl i det program, der gemmer dataene i DB - jeg henter nemlig nogle elforbrugs-data fra el selskaber, fx 24 poster (1 pr. time) og med et starttidspunkt. Her tager jeg ikke højde for sommertid, når jeg beregner klokkeslæt på de enkelte poster og gemmer i DB.
Lidt underligt, at jeg via mit php-script kan gemme et tidspunkt, der ikke eksisterer?

Jeg tester og leger lidt mere med dit aften.

Tak for input.

Jeg kan konstatere, at export-funktionen i phpMyAdmin bl.a. tilføjer denne linje i toppen af SQL-filen:

Den løser problemet.
Men jeg retter i stedet min programkode, der gemmer tidsstemplet, så der ikke gemmes tidspunkter, der ikke eksisterer - det må være det rigtige.

Tak for jeres input.