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í
×
dnes 17:11 | Komunita

Byl proveden bezpečnostní audit svobodného IMAP a POP3 serveru Dovecot (Wikipedie). Audit byl zaplacen z programu Mozilla Secure Open Source a provedla jej společnost Cure53. Společnost Cure53 byla velice spokojena s kvalitou zdrojových kódu. V závěrečné zprávě (pdf) jsou zmíněny pouze 3 drobné a v upstreamu již opravené bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
dnes 15:30 | IT novinky

Nadace Raspberry Pi představila na svém blogu Raspberry Pi Compute Module 3 (CM3 a CM3L), tj. zmenšené Raspberry Pi vhodné nejenom pro průmyslové využití. Jedná se o nástupce Raspberry Pi Compute Module (CM1) představeného v dubnu 2014. Nový CM3 vychází z Raspberry Pi 3 a má tedy dvakrát více paměti a desetkrát větší výkon než CM1. Verze CM3L (Lite) je dodávána bez 4 GB eMMC flash paměti. Uživatel si může připojit svou vlastní. Představena byla

… více »
Ladislav Hagara | Komentářů: 0
dnes 01:23 | Nová verze

Oficiálně bylo oznámeno vydání verze 3.0 multiplatformního balíku svobodných kancelářských a grafických aplikací Calligra (Wikipedie). Větev 3 je postavena na KDE Frameworks 5 a Qt 5. Krita se osamostatnila. Z balíku byly dále odstraněny aplikace Author, Brainstorm, Flow a Stage. U Flow a Stage se předpokládá jejich návrat v některé z budoucích verzí Calligry.

Ladislav Hagara | Komentářů: 5
včera 15:25 | Nová verze

Bylo oznámeno vydání první RC (release candidate) verze instalátoru pro Debian 9 s kódovým názvem Stretch. Odloženo bylo sloučení /usr jako výchozí nastavení v debootstrap. Vydán byl také Debian 8.7, tj. sedmá opravná verze Debianu 8 s kódovým názvem Jessie.

Ladislav Hagara | Komentářů: 6
včera 13:37 | Zajímavý projekt

1. ledna byl představen projekt Liri (GitHub). Jedná se o spojení projektů Hawaii, Papyros a původního projektu Liri s cílem vyvíjet operační systém (linuxovou distribuci) a aplikace s moderním designem a funkcemi. Včera byl představen Fluid 0.9.0 a také Vibe 0.9.0. Jedná se o toolkit a knihovnu pro vývoj multiplatformních a responzivních aplikací podporující Material Design (Wikipedie) a volitelně také Microsoft Design Language (designový jazyk Microsoft) [reddit].

Ladislav Hagara | Komentářů: 5
14.1. 00:33 | Zajímavý software

Google na svém blogu věnovaném open source představil knihovnu pro komprimaci a dekomprimaci 3D grafiky s názvem Draco. Knihovna bude využívána například v aplikacích pro virtuální a rozšířenou realitu. Porovnání Draco s gzip na YouTube. Zdrojové kódy Draco jsou k dispozici na GitHubu pod licencí Apache 2.0.

Ladislav Hagara | Komentářů: 5
13.1. 17:27 | IT novinky

V loňském roce proběhla úspěšná kampaň na Indiegogo na podporu GPD Win. Jedná se o malý 5,5 palcový notebook a přenosnou herní konzoli v jednom. Předinstalované Windows 10 lze nahradit Linuxem. V únoru by se na Indiegogo měla objevit kampaň na podporu 7 palcového notebooku GPD Pocket.

Ladislav Hagara | Komentářů: 30
13.1. 02:00 | Nová verze

Po pěti měsících od vydání verze 1.0.0 (zprávička) byla vydána verze 2.0.0 frameworku Kirigami (HIG) pro vytváření uživatelských rozhraní mobilních a konvergentních aplikací nad toolkitem Qt. Pro vyzkoušení je určena aplikace pro Android Kirigami gallery.

Ladislav Hagara | Komentářů: 0
12.1. 23:28 | Zajímavý software

Akční hra Lugaru HD od Wolfire Games (recenze) byla uvolněna jako svobodný software, a to včetně dat (pod licencí Creative Commons Attribution – Share Alike). Linuxový port byl v roce 2010 součástí první akce Humble Indie Bundle a engine byl krátce poté uvolněn pod licencí GNU GPL, což vedlo mj. k portu na AmigaOS. Autor mezitím pracuje na pokračování nazvaném Overgrowth.

Fluttershy, yay! | Komentářů: 0
12.1. 14:49 | Bezpečnostní upozornění

Na serveru Jabb.im bylo zveřejněno vyjádření k úniku dat z Jabbim Archive (pastebin). Dump databáze obsahuje komunikaci uživatelů, jejich IP adresy a logy aplikace od října 2015 do března 2016. Celkově se jedná o 8 GB dat, převažujícím jazykem zpráv je čeština a slovenština. O úniku informoval jako první server Motherboard. Jabbim Archive byla službou volitelnou, dostupnou pouze pro VIP uživatele. Podle provozovatele serveru Jabb.im k

… více »
Michal Makovec | Komentářů: 68
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (10%)
 (2%)
 (75%)
 (3%)
 (10%)
Celkem 295 hlasů
 Komentářů: 19, poslední 13.1. 22:02
    Rozcestník
    Reklama

    Dotaz: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo

    9.10.2011 08:04 datetime
    Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Přečteno: 5379×
    Ahoj, docela úspěšně jsem se zamotal do přepočítávání časů. V aplikaci ukládám některé časy v UTC. Pokud budu chtít v létě zobrazit 1.1. 2000 12:00:00 UTC, na jakou hodnotu to mám přepočítat (+1 nebo +2 hodiny)? Pokud budu chtít uložit čas do UTC, kolik hodin mám odečítat? Má se to vztahovat na aktuální čas nebo na datum a čas který ukládám (tj. má se v létě uložit 1.1. 2000 12:00:00 s -1 hodinou protože je ten samotný čas v zimě nebo s -2 hodinami protože ho vlastně ukládám v létě)? Jedná se o webovou aplikaci a uživatel zadává tyto časy do formulářů. Nezadává ale časovou zónu - to už je na uživatele trošku moc. Proto se má aplikace nějak implicitně chovat a nějak jsem se začal ztrácet v tom, jaké chování by bylo nejlogičtější.

    Odpovědi

    9.10.2011 08:20 Skokan, Pavel | skóre: 29
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    zalezi pro jake casove pasmo to chcete

    SEC stredo evropsy cas = CET central european time

    SELC stredo evropsky letni cas = CEST central european summer time

    UTC universal time coordinated = drivejsi GMT Greenwich mean time

    CET = UTC + 1

    CEST = UTC + 2

    9.10.2011 09:59 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Uživatel bude v drtivé většině případů zadávat datum a čas v časovém pásmu, které je platné pro zadaný datum a čas – tj. když si teď „v létě“ bude do kalendáře poznamenávat schůzku na listopad, bude ji zadávat už v SEČ. Takže přičítáte/odečítáte 2 hodiny pro SELČ, 1 hodinu pro SEČ podle časového pásma, které platí pro uživatelem zadaný čas. Pro dobu 2:00:00–2:59:59 poslední neděli v říjnu nejde o časovém pásmu pro čas zadaný uživatelem rozhodnout – tato doba je v SELČ i SEČ. Nezbývá, než se v takovém případě zeptat uživatele. Naopak doba 2:00:00–2:59:59 poslední neděli v březnu neexistuje v žádném časovém pásmu a takový čas byste měl odmítnout.
    9.10.2011 14:01 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Nějak nechápu co řešíš ?

    Prostě nic nepřepočítávej, na serveru nastav správné časové pásmo a porovnávej čas co zadal uživatel s tím co vrátí server. (který bude mít správně nastavené časové pásmo)

    Protože aplikaci stejně bude funkční jenom v ČR - případně ve stejném časovém pásmu, pokud bys tam chtěl přistupovat i z jiných časových pásem (třeba z USA) tak by jsi musel po uživatelovy chtít zadávat i časové pásmo kde je jinak nemáš šanci spočítat správný čas.
    9.10.2011 14:47 datetime
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Já hlavně řeším dilema, zda ukládat v databázi (mysql) data jako timestamp nebo jako datetime. Nechápu, jak mysql v případě timestampu rozhodne, do jakého časového pásma má čas interně uložený v utc převést. Dejme tomu, že podle utc je čas zimní, ale po převedení do aktuálního pásma je už letní. Jak se tohle řeší v případě použití časové zóny Europe/Prague (místo výchozího SYSTEM a tvrdého offsetu pro jakékoli časy)?
    9.10.2011 15:11 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Dejme tomu, že podle utc je čas zimní
    To je nesmysl, UTC je konkrétní časové pásmo, takže žádný zimní nebo letní čas nerozlišuje. „Zimní“ nebo letní čas znamená, že se pro danou geografickou oblast při neuvedení časového pásma myslí po část roku jedno pásmo (např. CET) a po jinou část roku jiné časové pásmo (např. CEST).

    MySQL při přepočtu používá aktuální časovou zónu (serveru nebo spojení), což je pro uživatele špatně – ten očekává zobrazení v časové zóně platné pro zadané datum, ne pro aktuální (když dnes naplánuju štědrovečerní večeři na 18:00, myslím tím 18:00 SEČ, i když dnes platí SELČ).

    Jak už jsem psal, převádějte to podle časové zóny platné pro uživatelem zadaný datum a čas – přičemž pro tu jednu hodinu v říjnu se musíte uživatele buď zeptat, jaké časové pásmo myslel, nebo některé vybrat automaticky (s tím, že pak uživatel nebude moci zadat časový údaj v rámci té jedné hodiny v roce).
    9.10.2011 15:35 datetime
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    A pro případy čistě informativní tzn. třeba bych chtěl zobrazit, kdy byl uživatel založen a tento údaj je v UTC. Řekněme, že je zrovna letní období a uživatel byl založen 1.1. 2000 12.00 UTC. Je rozumnější zobrazit, že uživatel byl založen v 13.00 (protože v zimě) nebo ve 14.00, protože se nacházíme v letním období?
    9.10.2011 15:55 Skokan, Pavel | skóre: 29
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    udalosti minule musite vztahovat k obdobi, ve kterem byly

    tedy 1.1.2000 13:00 UTC = 1.1.2000 14:00 CET

    a 1.6.2000 14:00 UTC = 1.6.2000 16:00 CEST
    9.10.2011 16:25 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Uživatel vždy předpokládá čas v časové zóně, která je v daném okamžiku platná. Když máte údaj v UTC, je převod triviální – od 1:00 UTC poslední neděle v březnu do 0:59 UTC poslední neděle v říjnu platí SELČ, po zbytek roku SEČ.
    10.10.2011 11:52 Sten
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Nastavte, že pro lokální čas používáte časovou zónu "Europe/Prague" a používejte vhodné převodní funkce. V PHP je na to třída DateTime.
    10.10.2011 14:45 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Lokální časová zóna systému se týká aktuálního data a času. Když ji použijete i pro údaje v minulosti a budoucnosti, bude se počítat špatně – když si dnes zadám do kalendáře připomínku na půlnoční přípitek 31. prosince, myslím tím půlnoc SEČ, ne SELČ.
    10.10.2011 14:51 Sten
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Když použijete Europe/Prague, použije se SEČ nebo SELČ podle toho, jaké datum tam dodáte (včetně toho, že to funguje správně i v poměrně dlouhé minulosti, třeba před zavedením letního času). Ale pokud tam dáte jenom čas, tak ten systém nemá jak zjistit, že myslíte 31. prosince, a použije aktuální zónu.
    10.10.2011 15:17 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Tj. musí se použít příslušná časová zóna přímo v té třídě DateTime, ne v nastavení systému (já jsem váš komentář původně pochopil druhým způsobem). Jak se to chová v té přelomové hodině, např. 30.10.2011 2:30:00? Nemám teď nikde PHP5, abych si to mohl vyzkoušet…
    10.10.2011 15:31 Sten
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Můžete použít i nastavení systému, ale potřebujete něco, co umí to nastavení používat (PHP to neumí) :-)

    Ani já to teď nemám jak zjistit, ale myslím, že to použije aktuální offset.
    10.10.2011 16:08 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Když nemáte, tak já Vám pomůžu (ať něčím přispěji :-)):
    Kód:
    Format(DateTime::ISO8601);
    echo  '
    '; $v='30.10.2011 1:59:59'; $d = new DateTime($v); echo "$v => " . $d->Format(DateTime::ISO8601); echo '
    '; $v='30.10.2011 2:00:01'; $d = new DateTime($v); echo "$v => " . $d->Format(DateTime::ISO8601); echo '
    '; $v='30.10.2011 2:10:00'; $d = new DateTime($v); echo "$v => " . $d->Format(DateTime::ISO8601); echo '
    ';
    30.10.2011 1:50:00 => 2011-10-30T01:50:00+0200
    30.10.2011 1:59:59 => 2011-10-30T01:59:59+0200
    30.10.2011 2:00:01 => 2011-10-30T02:00:01+0100
    30.10.2011 2:10:00 => 2011-10-30T02:10:00+0100
    
    PS: Default časová zóna se v PHP nastavuje explicitně v php.ini a pokud není, nebo je třeba ji změnit, tak se přestaví pomocí fce date_default_timezone_set()
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    10.10.2011 16:18 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Jejda nějak jsem zapomněl nahradit html entity, takže pro jsitotu oprava php kódu:
    <?php
    date_default_timezone_set('Europe/Prague');
    $v='30.10.2011 1:50:00';
    $d = new DateTime($v);
    echo "$v =&gt; " . $d->Format(DateTime::ISO8601);
    echo "<br />\n";
    $v='30.10.2011 1:59:59';
    $d = new DateTime($v);
    echo "$v =&gt; " . $d->Format(DateTime::ISO8601);
    echo "<br />\n";
    $v='30.10.2011 2:00:01';
    $d = new DateTime($v);
    echo "$v =&gt; " . $d->Format(DateTime::ISO8601);
    echo "<br />\n";
    $v='30.10.2011 2:10:00';
    $d = new DateTime($v);
    echo "$v =&gt; " . $d->Format(DateTime::ISO8601);
    echo "<br />\n";
    
    
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    Voty avatar 10.10.2011 15:57 Voty | skóre: 12 | blog: gemini
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Převést 30.10.2011 2:30:00 na UTC v podstatě nelze.

    Systémově je problém v tom, že jednoznačnému určení času potřebuju celý název i s konkrétní zónou (buďto SEČ/SELČ nebo Prague + příznak DST), protože jinak prostě existují časy, které při nejlepší vůli nevíte jak převést nebo neexistují. Aneb víme to přesně na sekundu +/- hodina :)

    Ale jinak pro potřeby kalendáře je jasné, že když uživatel zadá 18:00 25.12.2011, tak chce, aby těch 18:00 platilo 25.12.2011 a ne, když to zadával. Takže podle mě použít DATETIME.
    Jednu rozbil a tu druhou ztratil.
    10.10.2011 21:29 pht | skóre: 48 | blog: pht
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Lokální časová zóna systému se týká aktuálního data a času. Když ji použijete i pro údaje v minulosti a budoucnosti, bude se počítat špatně – když si dnes zadám do kalendáře připomínku na půlnoční přípitek 31. prosince, myslím tím půlnoc SEČ, ne SELČ.

    Tohle dělá problém jen když máte v systému natvrdo SEČ (+0100) a pak to jednou v neděli magicky přenastavíte na +0200 (viz známé "systém windows přenastavil...").

    Aby se to počítalo správně bez ohledu na to kolik je _teď_ a jak se počítá letní čas _letos_, tak se používají plovoucí časové zóny typu Europe/Prague, kde jsou všechny tyhle věci zakódovány a počítá se to správně.

    Co se týče hlavního dotazu, tak bych v tom nehledal vědu a určitě bych se to nesnažil dělat ručně - stačí použít právě nějakou systémovou funkci s příslušným časovým pásmem. To může být buď natvrdo ČR, nebo se můžete uživatele zeptat v jaké oblasti se zrovna nachází.
    In Ada the typical infinite loop would normally be terminated by detonation.
    Josef Kufner avatar 16.10.2011 10:42 Josef Kufner | skóre: 66
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Nedávno jsem měl stejný problém.

    Na začátku si nastav jak v aplikaci, tak v MySQL stejné časové pásmo a pak používej TIMESTAMP. Vše se bude chovat tak jak to uživatel očekává a vše uvidí ve svém místním čase.

    Případně můžeš použít DATETIME, vrámci aplikace i databáze mít vše v UTC a přepočítávat to až při zobrazení/zadání do uživatelova lokálního času. Tedy na úplně druhém konci aplikace než při použití TIMESTAMP, jinak je to zcela ekvivalentí řešení.

    Btw, UTC nemá letní/zimní čas, kdežto GMT ano a proto se zavedlo UTC.
    Hello world ! Segmentation fault (core dumped)
    16.10.2011 16:54 pavel
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Btw, GMT ani UTC nemá letní/zimní čas.
    Josef Kufner avatar 17.10.2011 10:32 Josef Kufner | skóre: 66
    Rozbalit Rozbalit vše Re: Správný způsob přepočítávání UTC data a času na aktuální časové pásmo
    Hmmm, podivné. Nevím už kde, ale někde to mají špatně napsané.
    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.