abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 20:00 | Komunita

OneDrive pro firmy je již ve webových prohlížečích na Linuxu stejně rychlý jako na Windows. Microsoft opravil chybu z listopadu loňského roku. OneDrive pro firmy běžel na Linuxu mnohem pomaleji než na Windows. V popisu chyby bylo uvedeno, že stačilo v prohlížeči na Linuxu nastavit v user-agentu Windows a vše se zrychlilo. Odpovědí Microsoftu bylo (Internet Archive: Wayback Machine), že Linux není podporován. Po bouřlivých diskusích na redditu i Hacker News byla chyba nalezena a opravena.

Ladislav Hagara | Komentářů: 3
včera 19:00 | Zajímavý projekt

Byla vyhlášena soutěž Hackaday Prize 2017. Soutěž je určena vývojářům open source hardwaru. Pro výherce je připraveno celkově 250 tisíc dolarů. Každý ze 120 finalistů získá tisíc dolarů. Nejlepší pak navíc 50, 30, 20, 15, 10 a 5 tisíc dolarů. Jedná se již o čtvrtý ročník soutěže. V roce 2014 zvítězil projekt globální sítě open source pozemních satelitních stanic SatNOGS. V roce 2015 zvítězil open source systém pro řízení elektrických invalidních vozíků pohybem očí Eyedriveomatic. V roce 2016 zvítězil modulární robot Dtto.

Ladislav Hagara | Komentářů: 0
včera 15:00 | Bezpečnostní upozornění

Byla vydána Samba ve verzích 4.6.1, 4.5.7 a 4.4.12. Řešen je bezpečnostní problém CVE-2017-2619. Pomocí symbolických odkazů a souběhu (symlink race) lze "teoreticky" získat přístup k souborům, které nejsou sdíleny. Linuxové distribuce jsou postupně aktualizovány (Debian).

Ladislav Hagara | Komentářů: 0
včera 07:43 | Nová verze

Na Steamu se objevil port hry Arma: Cold War Assault (Operation Flashpoint) pro Mac a Linux. … více »

creon | Komentářů: 25
včera 05:55 | Nová verze

Po 18 měsících od vydání verze 8.0 byla vydána verze 9.0 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab. Představení nových vlastností v příspěvku na blogu a na YouTube.

Ladislav Hagara | Komentářů: 0
včera 03:33 | Komunita

Platnost posledního patentu souvisejícího s Dolby Digital (AC-3) vypršela. Po MP3 se tak do Fedory oficiálně dostane také kodek AC-3.

Ladislav Hagara | Komentářů: 5
včera 00:44 | Komunita

Feral Interactive, společnost zabývající se vydáváním počítačových her pro operační systémy macOS a Linux, nabízí své hry na Steamu vývojářům open source 3D grafické knihovny Mesa zdarma. Podmínkou je minimálně 25 commitů za posledních 5 let. Stejnou nabídku dostali vývojáři knihovny Mesa v roce 2015 od Valve. O rok dříve dostali od Valve tuto nabídku vývojáři Debianu a Ubuntu.

Ladislav Hagara | Komentářů: 0
22.3. 23:55 | Nová verze

Opera 44, verze 44.0.2510.857, byla prohlášena za stabilní. Nejnovější verze tohoto webového prohlížeče je postavena na Chromiu 57. Z novinek vývojáři Opery zdůrazňují podporou Touch Baru na nejnovějších MacBoocích Pro (gif). Přehled novinek pro vývojáře na blogu Dev.Opera.

Ladislav Hagara | Komentářů: 1
22.3. 20:56 | Pozvánky

V úterý 28. dubna se koná další Prague Containers Meetup. Přijďte si zopakovat, jak psát kvalitnější Dockerfile a jaké novinky a ulehčení přináší ansible-container, který vám umožní spravovat celý životní cyklus vašeho kontejneru. Místo konání: Concur, Bucharova 11, Praha-Stodůlky.

little-drunk-jesus | Komentářů: 0
22.3. 17:00 | Nová verze

Po půl roce od vydání verze 3.22 bylo vydáno GNOME ve verzi 3.24 s kódovým názvem Portland. Vydání obsahuje 28 459 změn od přibližně 753 přispěvatelů. Z novinek lze zmínit funkci noční světlo, přepracovaná nastavení, aplikaci Recepty, zdokonalenou oblast pro upozornění nebo zdokonalený webový prohlížeč. Podrobnosti i s náhledy v poznámkách k vydání a v novinkách pro vývojáře a správce systémů.

Ladislav Hagara | Komentářů: 11
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (14%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 921 hlasů
 Komentářů: 72, poslední 1.3. 11:16
    Rozcestník

    Dotaz: Ukládání budoucích časů vs. letní čas

    Josef Kufner avatar 2.7.2011 11:29 Josef Kufner | skóre: 67
    Ukládání budoucích časů vs. letní čas
    Přečteno: 1027×
    Zrovna píšu jednu aplikaci, se kterou budou pracovat lidé v různých časových pásmech současně. Původně jsem si říkal, že bude stačit ukládat všechny časy v UTC a podle aktuálního nastavení časové zóny klienta ho správně přepočítávat. To lze celkem lehce v MySQL udělat použitím sloupců typu TIMESTAMP a nastavováním časového pásma per session (SET time_zone = '...').

    Ovšem narazil jsem na malou zákeřnost: Pokud uložím do databáze v zimě čas, který je v létě, tak až se na tento záznam podívám v létě, bude o hodinu posunut, protože jsem mezitím změnil časové pásmo z +1:00 na +2:00.

    Takže to takle jednoduché nebude.

    Jak tedy na to? Nevíte o nějakém ověřeném a jednoduchém způsobu používaném v kalendářích?

    Na webu je na toto téma hromada textu, ale prakticky všechny jsou dosti pochybné a často i zjevně chybné. Dokonce jsem našel i diskuze o chybě v Google Calendar týkající se letního času.

    Moje aplikace je klasické PHP 5.3 + MySQL, ale to není až tak podstatné.
    Hello world ! Segmentation fault (core dumped)

    Řešení dotazu:


    Odpovědi

    2.7.2011 12:24 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Něco je špatně. Buď to vy špatně používáte, nebo je chyba v MySQL. Když máte čas s časovou zónou, je jeho převod do jiné časové zóny vždy jednoznačný a není možné, aby se to přepočítávalo jednou správně a jednou špatně podle toho, zda je léto nebo zima. Letní a „zimní“ čas není nic jiného, než dvě časové zóny, mezi kterými se v konkrétní čas přepíná, a které představují pro danou oblast výchozí zónu, pokud se uvede čas bez uvedení zóny.

    Jinak v dokumentaci typů MySQL nevidím nic o časových zónách (že mě to u MySQL ani nepřekvapuje…), v MySQL Server Time Zone Support se píše, že timestamp se vždy ukládá v UTC a převádí se do aktuální časové zóny. Začal bych tedy tím, že se podíváte pomocí mysql klienta do databáze, zda tam ty časy máte správně a zda se správně převádí, když nastavíte různé časové zóny. Druhá věc je pak ještě zkontrolovat, jak se to chová v PHP, zda vám to náhodou nepřevádí mezi časovými zónami ještě podruhé.
    Jendа avatar 2.7.2011 12:53 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Podle mě máš chybu v tom, že v zimě paušálně ode všech ukládaných časů odečítáš 2 a ke všem zobrazovaným přičítáš 2 a v létě to samé s 1. Správně bys měl nejdřív posoudit, jaký bude v tom ukládaném datu platit čas, a podle toho to teprve přepočítat (tj. když v lednu ukládám červenec 14 hodin, do databáze se uloží 12 hodin). Jediný problém, který mě napadá, je, jak se má aplikace zachovat, když jí někdo zadá v lokálním čase ten_podzimní_den 2:30.
    Nezapomeňte si příští víkend posunout časovače na svých bombách o hodinu dopředu!
    2.7.2011 13:53 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Pokud tam nějaké hodiny přičítá nebo odčítá, je problém v tom přičítání/odčítání :-) 13:00 TZ+2:00 == 12:00 TZ+1:00 == 11:00 UTC, žádné přičítání nebo odčítání není potřeba. Akorát je potřeba počítat s tím, že uživatel očekává časovou zónu platnou v době zadávaného času, ne aktuální – takže je potřeba časovou zónu přepínat podle zadávaného/čteného data, ne podle aktuálního data. Tj. pokud zadávám nebo čtu datum a čas v prosinci, musím nastavit časovou zónu SEČ, bez ohledu na to, zda je zrovna aktuální SEČ nebo SELČ. Při zadávání času mezi 2:00 a 3:00 při přechodu z letního času na standardní je asi potřeba se uživatele na časové pásmo dotázat, protože to nijak nevyvěštíte.
    Jendа avatar 2.7.2011 14:41 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Akorát je potřeba počítat s tím, že uživatel očekává časovou zónu platnou v době zadávaného času, ne aktuální – takže je potřeba časovou zónu přepínat podle zadávaného/čteného data, ne podle aktuálního data.
    Jo, o to mi právě šlo. Jestli MySQL má tohle už nějak vyřešené, pak není co řešit. Z dotazu jsem nabyl dojmu, že si to přepočítávání píše sám.
    Nezapomeňte si příští víkend posunout časovače na svých bombách o hodinu dopředu!
    Josef Kufner avatar 2.7.2011 14:51 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Zatím ještě nepíšu (a ani nechci). Zjišťuju, jak se to dělá správně a trošku experimentuju.

    Zatím jsem ve stavu, kdy v PHP i MySQL nastavuju zónu na něco ve stylu "Europe/Prague" a používám sloupce typu TIMESTAMP. Ale nevím, zda to stačí a jestli tam nejsou schované nějaké problémy...
    Hello world ! Segmentation fault (core dumped)
    2.7.2011 17:06 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Nastavením časové zóny v PHP a MySQL ale určujete časovou zónu po aktuální čas. Vy ji ale potřebujete převádět vzhledem k datu a času, který ukládáte nebo zobrazujete. Když použijete aktuální časovou zónu, dopadne to tak, že uživatel teď zadá něco na prosinec 12:00 až 13:00, ale použije se aktuální časová zóna (tj. středoevropský letní čas), takže se to převede na 10:00 až 11:00 UTC. Až si to v prosinci zobrazí, bude aktuální „zimní“ čas a zobrazí se to jako 11:00 až 12:00 SEČ. To ale není chování, které uživatel očekává.
    Josef Kufner avatar 2.7.2011 17:20 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Já vím, proto tady tenhle dotaz je ;-)
    Hello world ! Segmentation fault (core dumped)
    2.7.2011 17:44 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    V tom případě ale nevím, na co se ptáte.
    2.7.2011 19:05 Sten
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Nevím konkrétně u PHP, ale MySQL a naprostá většina rozumných systémů nastavuje zónu geograficky a potom to funguje dobře pro zimní i letní čas, tj. pokud v létě použijete 24. prosince 13:00, bude to 12:00 UTC, a naopak pokud v zimě použijete 24. červen 14:00, bude to 12:00 UTC.
    2.7.2011 19:49 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    A pokud použiju 30. října 2011 2:30? Hádání časové zóny bez nápovědy uživatele obecně nemůže fungovat. Proto mají databáze, knihovny atd. pracovat vždy s dvojicí čas + časové pásmo, a pokud chce někdo časové pásmo hádat, měla by to dělat ta aplikace, která komunikuje s uživatelem. Ta jediná má dost informací a může se v případě potřeby zeptat.
    2.7.2011 20:28 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Pokud je řeč o časové zóně, tak ta už v sobě nese i informace o případném letním a zimním čase.
    2.7.2011 22:30 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    No právě. Takže teď uživatel zadá čas v SELČ, a v prosinci se mu zobrazí v SEČ, tedy o hodinu posunutý – když uživatel čas zadával, předpokládal totiž, že jej zadává v SEČ. Je tedy logické, aby aplikace uživateli vyšla vstříc a ten předpoklad splnila.
    3.7.2011 02:18 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Jen pokud je aplikace špatně napsaná. Pokud je napsaná správně, definice časové zóny obsahuje i informaci o tom, jaký je v daném okamžiku offset oproti UTC, takže se správně převede jak aktuální čas, tak jakýkoli čas v minulosti nebo budoucnosti (samozřejmě za předpokladu, že mezitím nedojde ke změně pravidel).
    3.7.2011 21:45 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Asi každý myslíme něco jiného časovou zónou. Já píšu o těch časových zónách, které jsou definovány posunem od UTC, takže třeba SEČ (+1 h.) nebo SELČ (+2 h.). Vy zřejmě píšete o časové zóně Evropa/Praha, která může být SEČ nebo SELČ, podle toho jak kdy.

    Problém je právě s určením toho časového okamžiku. Časový okamžik je určen právě časem a časovou zónou – když časová zóna chybí, může si aplikace něco domýšlet, ale to nebude vždy fungovat. I pokud dáme aplikaci také datum a aplikace bude mít pro daný rok správné údaje o přechodu na/z letní čas, pořád tam zbývá ta hodina při přechodu zpět na sluneční čas, kdy datum, čas a geografická časová zóna nestačí.
    3.7.2011 22:07 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Asi každý myslíme něco jiného časovou zónou.

    Očividně. Ale pokud se v souvislosti s unixovými systémy používá termín timezone (časová zóna), myslí se tím téměř vždy to, o čem mluvím já.

    pořád tam zbývá ta hodina při přechodu zpět na sluneční čas, kdy datum, čas a geografická časová zóna nestačí.

    Proto se také jako interní reprezentace používá ta vyjádřená pomocí time_t, která tímto problémem netrpí. A proto funkce mktime() v tom jednom speciálním případě přihlíží i k hodnotě položky tm_isdst; protože ale tento speciální případ (u většiny zón - z těch, které vůbec nějaký letní čas mají) pokrývá přibližně jednu setinu procenta roku (navíc pečlivě vybranou tak, aby se toho dělo pokud možno co nejméně), nikdo to obvykle moc neřeší.

    2.7.2011 14:53 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Ten časový okamžik se prostě musí převádět na interní reprezentaci jako celek - mimo jiné i proto, že pravidla pro letní čas se čas od času mění. Standardní knihovní funkce mktime() a localtime() resp. localtime_r() se o to postarají, otázkou jen je, jestli je autor software použije nebo jestli se spolehne na lidovou tvořivost.
    2.7.2011 13:35 Sten
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Nezadávejte zóny absolutně, ale geograficky:

    SET time_zone='Europe/Prague'

    Potom to funguje dobře.
    Josef Kufner avatar 2.7.2011 14:56 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Ukládání budoucích časů vs. letní čas
    Díky. Na tohle je potřeba importovat do MySQL data o zónách, což jsem předtím nějak minul...
    Hello world ! Segmentation fault (core dumped)

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.