D7VK byl vydán ve verzi 1.2. Jedná se o fork DXVK implementující překlad volání Direct3D 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána verze 12.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Současně byl ve verzi 12.0.0 vydán související modul pro Python libvirt-python. Přehled novinek v poznámkách k vydání.
CreepyLink.com je nový zkracovač URL adres, 'díky kterému budou vaše odkazy vypadat tak podezřele, jak je to jen možné'. Například odkaz na abclinuxu.cz tento zkracovač převádí do podoby 'https://netflix.web-safe.link/logger_8oIlgs_free_money.php'. Dle prohlášení autora je CreepyLink alternativou ke zkracovači ShadyURL (repozitář na githubu), který dnes již bohužel není v provozu.
Na blogu Raspberry Pi byla představena rozšiřující deska Raspberry Pi AI HAT+ 2 s akcelerátorem Hailo-10 a 8 GB RAM. Na rozdíl od předchozí Raspberry Pi AI HAT+ podporuje generativní AI. Cena desky je 130 dolarů.
Wikipedie slaví 25. výročí svého založení. Vznikla 15. ledna 2001 jako doplňkový projekt k dnes již neexistující encyklopedii Nupedia. Doména wikipedia.org byla zaregistrována 12. ledna 2001. Zítra proběhne v Praze Večer svobodné kultury, který pořádá spolek Wikimedia ČR.
Po více než dvou letech od vydání předchozí verze 2.12 byla vydána nová stabilní verze 2.14 systémového zavaděče GNU GRUB (GRand Unified Bootloader, Wikipedie). Přehled novinek v souboru NEWS a v aktualizované dokumentaci.
Google Chrome 144 byl prohlášen za stabilní. Nejnovější stabilní verze 144.0.7559.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 10 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře (YouTube).
Microsoft zveřejnil zdrojový kód XAML Studia a uvolnil ho pod MIT licencí. XAML Studio je nástroj ze světa Windows, určený pro tvorbu uživatelského rozhraní aplikací pomocí XAML (Extensible Application Markup Language). Stalo se tak zhruba po osmi letech od prvního prohlášení Microsoftu, že se tento kód chystá zveřejnit.
TimeCapsule, 'časová kapsle', je jazykový model trénovaný výhradně na datech z určitých míst a časových období, aby se tak napodobila autentická slovní zásoba, způsob vyjadřování a názory dané doby. Na Hugging face jsou k dispozici modely natrénované na historických textech dostupných v oblasti Londýna mezi lety 1800 až 1875.
Radicle byl vydán ve verzi 1.6.0 s kódovým jménem Amaryllis. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
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: