Datetime localization
-
I am trying to implement localization library. One of the items that are needed to properly localize date and time is the current system timezone. So lets see, what the standard library knows about it. Start simple:
$ LC_ALL=cs_CZ.UTF-8 date Čt říj 5 20:58:55 CEST 2017
WHAT? “CEST”? Is it making earthworms of me? The timezone is called “SELČ” in Czech.
Also, the order of items is just Absurd™. At least:
$ LC_ALL=cs_CZ.UTF-8 date +%c Čt 5. říjen 2017, 21:03:33 CEST
gets sane order of items (but isn't
%c
, the “locale's date and time” the default?). But it still says “CEST” for the timezone.
-
@bulb said in Datetime localization:
making earthworms of me
Is that a direct translation of a local idiom?
-
@masonwheeler It's a direct translation of something that probably isn't even an idiom.
Edit: Well, the phrase “it's making fun of me” has the same grammar structure in English as it does in Czech and then just replace ‘fun’ with something absurd.
-
-
@blakeyrat said in Datetime localization:
@bulb said in Datetime localization:
But it still says “CEST” for the timezone.
Isn't that correct?
I assume he expected the timezone to be translated and re-abbreviated into the locale language?
-
@tsaukpaetra I would expect there be one function for getting the internationally accepted time zone name, and another function for getting the time zone name localized to Czech (or the OS' current default language.)
The former is just a database key basically to identify the timezone. The latter is something you could show the user.
-
@blakeyrat said in Datetime localization:
@bulb said in Datetime localization:
But it still says “CEST” for the timezone.
Isn't that correct?
No,
@blakeyrat said in Datetime localization:
@tsaukpaetra I would expect there be one function for getting the internationally accepted time zone name, and another function for getting the time zone name localized to Czech (or the OS' current default language.)
And
date
is showing to the user, so it should be using the later. Except it does not seem to exist!And the former does seem to exist either. The actual database key is
"Europe/Prague"
(or its BCP47-equivalent"czprg"
), but I haven't found a documented way to get that. The only thing it gives me are the English abbreviations.As usual with localization, ItIsComplicated™. The timezone is
Europe/Prague
, which is in metazone"Europe_Central"
and that has the appropriate local names. The two steps are because historically the rules for daylight saving time were different in different countries, so more detailed distinction is needed for calculating timestamps in the past.
-
@bulb It might help us if you tell us WHAT OS/standard library you're using.
In Windows, GetTimeZoneInformation has localized names of the time zone for example:
The StandardName and DaylightName members of the resultant TIME_ZONE_INFORMATION structure are localized according to the current user default UI language.
-
@blakeyrat From the command used, I would suspect some Linux variant (LC_ALL is used on Linux [and other Unix-esque systems] to control localization).
-
@brisingraerowing Well if you're going to use a shitty OS glommed together by idiots instead of one actually designed by designers, you're gonna have a bad time.
-
@blakeyrat said in Datetime localization:
@tsaukpaetra I would expect there be one function for getting the internationally accepted time zone name, and another function for getting the time zone name localized to Czech (or the OS' current default language.)
The former is just a database key basically to identify the timezone. The latter is something you could show the user.
Btw, given apparently the "date" part of datetime string is translated to local format, I think it's kind of weird to not have other datetime parts translated.
-
@cheong On UNIX and therefore Linux you use zoneinfo files from IANA ("the Olson database"), keyed by
$continent/$city
, which have historical DST information going back centuries but curiously no capability for localization. All there is isCE%sT
.
-
Such fun...and you haven't even dealt with historical funnies :)