[Dict] Официален формат за време

[Sah War]

>
> По спомени от училище - записвахме минутите с по-малки букви, отгоре и
> по подобен начин минути и секунди 10²⁵ примерно
> Иначе - 10ч. 25мин.
>
> Аз съм много твърдо за двоеточие, твърдо против точка и много твърдо
> против запетая.
> В преводите на GNOME и всички останали ползвам двоеточие.
>
> И на малко по друга тема - при записа с двоеточие не използвам друг
> разделител:
> 10:23:58
> 10 часа, 23 минути и 58 секунди
>
>
Напълно съм съгласен с това мнение (освен по отношение на частта с
използването на знака hair space, което е просто ненужно усложнение и от
него има смисъл само в добре оформени електронни или печатни книги, а не в
интерфейса на една програма. ;) ).

Онова с изписването на минутите като горен десен индекс след часа е просто
дизайнерско хрумване, по подобен начин изписват и паричната стойност на
продукти в каталозите на големите вериги от магазини, но това не прави този
начин „правилен“; това е просто трик, който цели психологическо
пренебрегване на по-малката стойност (за стотинките или за минутите).

И е много объркващ като цяло, защото при паричните суми е нужна запетая (за
България), а без запетаята излиза, че цената е примерно 10²⁵ лв. ( :D ),
т.е. (10 на степен 25) лева. :) По-правилно е да се пише „10,²⁵ лв.“ (със
запетая) но това не изглежда добре в очите на дизайнерите, и вероятно
поради това не се използва толкова често (или просто дизайнерите са
неграмотни...).

10 часа, 23 минути и 58 секунди
>

Това е двусмислено поради т.нар. „условен правопис“ в българския език,
защото „10 часа“ може да означава „продължителност от цели 10 часа“, а в
случая по-скоро се има предвид „10 часа̀“ /десет час*ъ*/, т.е. часовото
време за даден момент. ;)

Според мен водеща нула може да се използва за месеца (макар да не е
> задължителна), но не и за датата от месеца.
>

Е, тук вече говорим за лични предпочитания и пак навлизаме във водите на
това „Кой ще си наложи предпочитанията като стандарт, който трябва да се
съблюдава от всеки(го)?“... :D

За очите на много потребители наистина е по-приятно да няма padding (т.е.
допълнителните нули) при числата от датите, но това би създало проблем за
програми, които се използват за сървъри и т.н. (в случай че сглупят да
използват български езиков пакет за такива неща :D ), т.е. ще доведе до
излишни нерви и ръчно писане на регулярни изрази за добавяне на липсващите
нули, поради това, че с тях по-лесно се сортират колоните в таблиците с
log-ове...

Целите на ISO 8601 са други -- да осигури недвусмислен начин за
> представяне на дати и време, особено когато данните се обменят между
> страни с различни традиции за записването.


Да, именно, ISO 8601 е създаден за целите на документи, които се споделят
между страни с различни традиции при форма̀та на датите и часовете, той не
е предвиден за вътрешна употреба в рамките на дадена страна (макар че често
се използва като автоматично генериран datetime stamp за уебстраници,
например чрез PHP).

Например при датите
> стандартът определя формат ГОДИНА-МЕСЕЦ-ДЕН, който, доколкото знам, не
> съответства на традициите на нито една държава.


Не е така, някои държави използват именно този формат, например Китай, Южна
Корея и Северна Корея, Япония (там се използва и стилът на изписване на
името от типа „фамилно име, лично име“, все нещата са формални и
„наобратно“ в голяма част от Азия. :D ), а и в някои други страни:
https://en.wikipedia.org/wiki/Date_and_time_representation_by_country и
https://en.wikipedia.org/wiki/Date_format_by_country#Map.

Поздрави,
Sah War (sahwar)

На 20 декември 2015 г., 17:17, Anton Zinoviev <anton at lml.bas.bg> написа:

> On Sun, Dec 20, 2015 at 05:01:28PM +0200, Alexander Shopov wrote:
> >
> > Това ли имаш предвид?
>
> О, нямах предвид нещо конкретно, само се подсетих за някои спомени.
>
> С поздрав: Антон Зиновиев
>
> _______________________________________________
> Dict mailing list
> Dict at ludost.net
> http://lists.ludost.net/cgi-bin/mailman/listinfo/dict
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ludost.net/pipermail/dict/attachments/20151221/201e4d90/attachment.html>