Rozsudky Soudního dvora Evropské unie ve věcech C-465/20 P (Apple) a C-48/22 P (Google a Alphabet): Irsko poskytlo společnosti Apple protiprávní daňová zvýhodnění ve výši 13 miliard eur a je povinné je získat zpět. Byla potvrzena pokuta ve výši 2,4 miliardy eur uložená společnosti Google za to, že zneužívala svého dominantního postavení tím, že upřednostňovala vlastní službu srovnávání výrobků.
Apache Cassandra (Wikipedie), tj. open source NoSQL distribuovaná databáze, byla vydána v nové major verzi 5.0. Přehled novinek v příspěvku na blogu a v souboru NEWS na GitHubu.
Společnost MNT Research oznámila, že po open source noteboocích MNT Reform a MNT Pocket Reform bude následovat MNT Reform Next. Časem se objeví na Crowd Supply. Vývoj lze sledovat na Mastodonu.
Apple představil (YouTube) telefony iPhone 16 Pro a iPhone 16, hodinky Watch Series 10 a Watch Ultra 2 a sluchátka AirPods 4, AirPods Pro 2 a AirPods Max.
Byla vydána verze 0.9.0 operačního systému Redox OS (Wikipedie). Jedná se o mikrokernelový unixový operační systém naprogramovaný v programovacím jazyce Rust. Zdrojové kódy jsou k dispozici na GitLabu pod licencí MIT. Z novinek lze vypíchnout aplikace Files, Editor a Terminal z desktopového prostředí COSMIC, RustPython nebo webový server Simple HTTP Server.
Dnes ve 23:59 končí hlasování o přednáškách na konferenci LinuxDays 2024, která proběhne o víkendu 12. a 13. října v Praze.
Vývojáři KDE ve spolupráci se společností Slimbook oznámili 16palcový notebook KDE Slimbook VI s předinstalovaným KDE Neon s Plasmou 6. Uvnitř se nachází procesor AMD Ryzen 7 8845HS s integrovanou grafickou kartou Radeon 780M.
Ve Würzburgu dnes začala konference vývojářů a uživatelů desktopového prostředí KDE Akademy 2024. Sledovat lze také online (YouTube, Mastodon, 𝕏, …)
Byla vydána nová major verze 14 svobodného systému pro řízení přístupu k síti (NAC) PacketFence (Wikipedie). Přehled novinek v oznámení o vydání. Pro uživatele předchozích verzí jsou k dispozici poznámky k aktualizaci.
Jak nahrávat zvuk z webového prohlížeče na Linuxu s PipeWire pomocí Nahrávání zvuku (Sound Recorder) a Helvum případně qpwgraph, článek na webu Libre Arts.
Ahoj, mam nasledujuci dotaz, ked zaznamenavam do db data z casovou znackou UTC, nasledne v aplikacii sa mi tento cas zobrazuje spravne s posunom +2 hod. Otazka znie, ked Spravym dotaz na databazu, v ktorom bude fixne vystupovat timestamp, odcita sa mi od tohoto casu casovy posun, alebo nie?
Nevím jak která databáze (nebylo uvedeno), ale timestamp je datový typ uchovávající většinou počet jednotek od nějakého data.
Tím pádem nemá údaj o časovém pásmu a předpokládal bych že se většinou zobrazí bez jakéhokoliv posunu, to znamená zapíši li tam například datum a čas přes NOW()
vloží se tam 2009-08-21 13:30:00.
a to tam bude a bez konverze se takto i vypíše bez ohledu na nastevní časové zóny v systému.
Ale například u MySql s sql_mode=MAXDB
je typ TIMESTAMP
v db zapisován jako typ DATETIME
.
Postgre, jestli se nepletu, ukládá TIMESTAMP
jako čas UTC a pokud není explicitně vynucena časová zóna při deklaraci datového typu TIMESTAMP with time zone
, použije se systémová, takž Postgre má v TIMESTAMP čas uložen vždy UTC, ale pro výpis se aplikuje systémová zóna nebo definovaná (doufám že jsem to nepoplet).
Záleží o co Vám přesně jde...
Ide o to ze ak si dam vypisat timestamp, a potom ho prekonvertujem cez utilitku "date" dostanem spravny cas. Ked vsak robim select a pouzijem funkciu db "from_unixtime" tak tam mam posun -5 hod. Db pouzivam MySql.
To je docela guláš..., vo co Vám go ?
Co je utilitka date
fce nějakého progr. jazyku ?
Jak se záznamy do db dostanou (přiložte kód a sql dotaz) ?
Jak se záznamy z db vybírají (přiložte kód a sql dotaz) ?
PS: Timestamp se z MySql vypisuje ve formátu YYYY-MM-DD HH:MM:SS
, pokud se přičte 0 dostane se reálné číslo. MySql funkce from_unixtime() konvertuje běžný 32bit integer do textové reprezentace datumu a času YYYY-MM-DD HH:MM:SS
.
MySql a unix timestamp jsou rozdílně uložené záznamy a neexistuje převod 1:1,
zkuste si například:
SELECT UNIX_TIMESTAMP('2009-03-29 02:00:00'); SELECT UNIX_TIMESTAMP('2009-03-29 03:00:00');
vrátí to stejný výsledek 1238288400 (posun na letní čas...).
kdežtože
SELECT TIMESTAMP('2009-03-29 02:00:00') + 0; SELECT TIMESTAMP('2009-03-29 03:00:00') + 0;
vrátí rozdílné výsledky.
No mne
SELECT UNIX_TIMESTAMP('2009-03-29 02:00:00');
vratilo 1238310000
a
SELECT UNIX_TIMESTAMP('2009-03-29 03:00:00'); vrat 1238313600
No vidíte a mně oba 1238288400 jak na widlich (XP, MySql 5.0.45-community-nt ) tak na Linuxu (SuSe 11.1, MySql 5.0.67).
Sice nerozumím tak velkému rozdílu, ale je z toho patrné, že fce UNIX_TIMESTAMP() vrací hodnotu závislou na nastavení systému, takže její kombinace s DB a aplikačním prostředím musí být správná a nemusí být přenositelná (nebo naopak přenositelnost zajistí :) ).
Nicméně to neřeší Váš problém, u kterého by stačilo přiložit kousek kódu a hned by bylo jasněji.
Peto predpokladam, ze myslis program date na linuxovej konzole, databaza zapisuje urcite spravne, chyba bude v rozdielnom nastaveni narodnych prostredi operacneho systemu a databazoveho systemu v danom pripade MySQL.
pozri si napriklad cez phpMyAmin premenne databazoveho systemu systemu
Konkretne si pozri
lc time names
potom zadaj an konzole pokial pouzivas linux prikaz locale
vrati ti nieco taketo vsimni si LC_TIME, hodnoty by mali byt totozne
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
Pokial pouzivas ako klienta este trebars php skontroluj si locale aj v nom
Tiskni Sdílej: