Kamēr tev ir lauks ar tipu datetime, tu tanī vari bāzt iekšā jebko un tieši tā tas arī tiks saglabāts. Nekādu laika zonu, nekā. Pat, ja vēlies. It kā normāli, jo 99% gadījumu datos nav ko turēt laika zonu.
@laacz tvītu arhīvs
Sakarā ar to, ka Twitter ir slēdzis bezmaksas piekļuves savam API, šis projekts var tikt uzskatīts par mirušu sākot ar 2023. gada 15. jūniju.
Šis ir tvitera pavediens. No senākā uz svaigāko. Tvītu skaits: 27
Ir lietas iekš MySQL, kuras man spēj tracināt. Viena no tādām ir laika zonu neesamība un vienlaicīgā esamība.
Ar jebko es domāju, ka lauka vari saglabāt gan 1000-01-01, gan 9999-12-31. Respektīvi, laika zona tiek ignorēta. Līdz ar to arī datumlaiks '2023-03-26 03:57:45' ir legāls. Un tev pašam jāzin, kas tā par laika zonu. Promska 99% gadījumu - UTC.
Ar optimizāciju es domāju vietu uz diska. Senos laikos DATETIME bija 8 baiti, TIMESTAMP - 4. Mūsdienās starpība vairs nav tik liela, jo DATETIME tagad aizņem 5 baitus, kamēr neglabā sekundes daļas (bet tas palielinātu arī TIMESTAMP aizņemto vietu).
Bet tad atnāk draugs, kurš veiks nelielu optimizāciju. Lai viss būtu skaistāk, izmantos TIMESTAMP datu tipu. Tehniski tās ir sekundes kopš 1970-01-01. Biznesa prasības atļauj. Nu, labi. Lai jau tiek.
Jo, raugi, lai pārvērstu laiku milisekundēs, mysql šoreiz izdomā, ka tu gaņauka norādi laiku noklusētajā servera laika zonā, nevis UTC (jā, jo kāpēc gan lai tā nebūtu?). Un līdz ar to, ka pārejot uz vasaras laiku, šāds pulksteņlaiks neeksistē, vari iet atā.
Atgriežoties pie "tā takš ir mikrooptimizācija, nekas slikts takš nenotiks". Kā tad.
Laika zonas ir skarbi. Tās vajag nelietot, kad nevajag nelietot. Visu vienmēr glabā UTC, visu vienmēr glabā kā timestamp. Un arī tad datu līmenī operē ar milisekundēm, nevis datumiem un laikiem. Attēlojot vari darīt ko gribi.
Bet, nu, kā mēs zinam, ceļš no pārlūka datumlaika ievades līdz milisekundēm serverī var būt diezgan garš un viltīgs, ja nerūpējies par katru soli. Taču par to nav stāsts.
@laacz Saprotama sāpe. Incidentu izmeklēšanā notikumu kārtošana laika asī ir diezgan noderīga. Tad sākas jandāliņš ar operetājsistēmām, programmatūru, laika zonām un tā visu pierakstu dažādos žunālos…
@laacz Vai arī lieto postgresu un timestamptz. Mysqls ir mazohistu datubāze
@laacz Ir tāda lieta kā standarti. Šajā gadījumā ANSI SQL standarts.
@juzislv Protams, tāpēc postgres vairumā gadījumu ir labāka izvēle par mysql, lai gan no setapa un uzturēšanas viedokļa ir čakarīgāk, nekā "sudo apt install mysql-server".
@shulcsm Piekrītu par postgresu, bet mysql vairumā gadījumu ir good enough, kamēr nesastopies ar tā īpatnībām.
@laacz Biju vairāk domājis par to kāpēc ar DATETIME ir tā kā ir vai tur postgres, mysql vai kas.
@juzislv Ā, mans rants vairāk bija par mysql un timestamp un laika zonām.
@laacz @juzislv Date strings vienmēr ir grābeklis. Izmantoju tikai timestamp. Nav jau ko arī pa ceļam tur daudz konvertēt. Pie pirmās iespējas uz kādu Date objektu ar tz vai uzreiz ņemt timestamp. Nav runa par diska vietu, bet gan par mazāk grābekļiem.
@laacz MySQL vienmēr šo insert vērtību sapratīs kā current time zone. Pēc noklusējuma tā ir servera time zone. "MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current .." Pārlasīju manuāli: https://dev.mysql.com/doc/refman/8.0/en/datetime.html
@martinsbalodis @juzislv Timestamp reprezentācija RDBMS vienmēr ir datumlaika strings/objekts.
@ValdisBluzma Jep, tieši to es arī mēģināju pateikt.
@laacz Bet, ja tu to zini un paturi prātā, tad nevajadzētu būt čakaram, jo timestamp iekšā jau glabājas UTC. Tam max, min values diapazons ir UTC. Nu, mysql vienmēr konvertēs un vienmēr no current time zone. Savukārt, ko klients padod, viņš nezina Es laikam nesapratu problēmu.
@laacz Ja klients ir pats kaut ko konvertējis "insert" vērtībai, mysql tāpat to VIENMĒR sapratīs kā current time zone - parasti servera. Klienta atbildība.
@ValdisBluzma Tieši tā. Bet tā ir gotcha, šo niansi nezinot. Es, tiesa, nezinu vai tas ir ANSI SQL definēts behaviour, bet Postgresql defaultojas uz "ok, UTC", neatkarīgi no klienta/servera laika zonas. TZ ir tikai tad, ja tārgets ir ar tiemstamptz. Un pat tad tas nefeilo, bet gan pārveido.
@laacz Vēl skarbāk ir tad, ja "vēsturisku iemeslu" dēļ šos laikus glabā nevis utc, bet tur teiksim Eurpoe/Amsterdam, un nu jau ir desmit gadi par vēlu lai veiktu migrāciju un vienkārši pieņem, ka divreiz gadā būs jautrība
@ramuuns Ir lietas, kuras jau 20 gadus ir par vēlu. 20 gadus, Ramūn.
@laacz Tas gan, loģiskāks default ir postgresql. Par "fails", tur var strīdēties. MySQL tā vērtība ir current tz, bet postgresql utc + convert to time zone. Bet jā, suputroties var :-)