Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001005 [1003.1(2008)/Issue 7] Base Definitions and Headers Editorial Enhancement Request 2015-11-10 10:29 2016-07-21 16:31
Reporter EdSchouten View Status public  
Assigned To ajosey
Priority normal Resolution Rejected  
Status Closed  
Name Ed Schouten
Organization Nuxi
User Reference
Section <time.h>
Page Number
Line Number
Interp Status ---
Final Accepted Text
Summary 0001005: Add support for thread-safe timestamp conversion across timezones
Description The routines that can convert between time_t and struct tm (gmtime, gmtime_r, localtime, localtime_r and mktime) have a couple of shortcomings that make it hard to use these interfaces in practice:

1. The mktime function is the inverse of localtime, but no such function exists for gmtime. Most operating systems provide timegm, though.

2. There is no elegant way of querying the timezone database for arbitrary timezones and using those to convert timestamps. Existing practice seems to be to call "setenv("TZ", "...", 1); tzset();", but the disadvantage of this approach is that it is not thread-safe. This affects the behavior of localtime, localtime_r and mktime within the entire process. This makes it impossible to sanely use these functions as part of a library function that needs to deal with arbitrary timezones (parse email headers, generate calendar appointments for people across timezones, etc).

Optional: 3. Functions like strftime provide no way of formatting timestamps with sub-second precision. Many other languages do provide support for this. Python's datetime.strftime() supports %f. Rust's tm structure provides tm_nsec.

It would be nice if these issues could be addressed in an upcoming version of the standard. This is an issue that has been bothering people for some time now. An older proposal by Markus Kuhn from 2004: https://www.cl.cam.ac.uk/~mgk25/time/c/. [^]
Desired Action For CloudABI's C library (https://github.com/NuxiNL/cloudlibc) [^] I solved this alternatively by integrating the concept of timezones into locale handles (locale_t). In my opinion this is a lot simpler and more elegant than what Markus proposed, which was of course prior to the introduction of locale handles. In essence, I added the following extensions:

<locale.h>:

- Add LC_TIMEZONE_MASK.
- Let LC_ALL_MASK include LC_TIMEZONE_MASK.

<time.h>:

- Add 'long tm_nsec' to the tm structure.
- Add the following two functions:

int localtime_l(const struct timespec *restrict, struct tm *restrict, locale_t);
int mktime_l(const struct tm *restrict, struct timespec *restrict, locale_t);

Below is an example of how you could use these extensions to return the current time for a given timezone.

int get_time_in_timezone(const char *tzname, struct tm *tm) {
  // Get time of day.
  struct timespec ts;
  if (clock_gettime(CLOCK_REALTIME, &ts) != 0)
    return -1;

  // Obtain timezone that we want to use to format.
  locale_t l = newlocale(LC_TIMEZONE_MASK, tzname, (locale_t)0);
  if (l == (locale_t)0)
    return -1;

  // Convert to local time.
  int ret = localtime_l(&ts, tm, l);
  freelocale(l);
  return ret;
}

Notice that mktime_l() is different from mktime() in the sense that the tm structure is marked const. This is done for two reasons:

1. If you look at the simplest algorithm of converting a struct tm to a UNIX timestamp, there is no intermediate step that yields a normalized struct tm. C libraries like musl and CloudABI's C library effectively need to call into localtime() to do the normalization. This adds unneeded CPU overhead.

2. It eliminates edge cases where mktime() needs to return EOVERFLOW, even though the conversion to a UNIX timestamp itself succeeds. Only the normalization step failed.

The final question becomes, what would locale names look like with this model? In my implementation I decided to append the timezone name to the end of the locale name, using @:

locale_t l = newlocale(LC_ALL_MASK, "nl_NL.UTF-8@Europe/Amsterdam", (locale_t)0);

If you're only interested in LZ_TIMEZONE_MASK, it is valid to omit the first part of the locale name:

locale_t l = newlocale(LC_TIMEZONE_MASK, "@Europe/Amsterdam", (locale_t)0);

Unfortunately, this was a bad decision, as it turns out locale names can already be suffixed with a @-modifier at the end (POSIX issue 7, section 8.2). I guess we should pick a different character. Any special character would do in my opinion.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0002898)
jsm28 (reporter)
2015-11-10 16:38

The most appropriate interfaces for this purpose would be those such as localtime_rz, present in the tz code (https://github.com/eggert/tz.git) [^] and inspired by NetBSD.
(0002899)
EdSchouten (updater)
2015-11-10 17:02
edited on: 2015-11-10 17:34

Oh, cool. I wasn't aware that those interfaces eventually made it into NetBSD.

So in my opinion both of these sets of interfaces (CloudABI's and NetBSD's) look interesting. Rough comparison that I can come up with:

NetBSD's interfaces:
+ Incremental change on top of existing APIs.
+ Implementation exists as part of the official TZ code.
- Localization is no longer performed through a single handle. We now have locale_t and timezone_t. This may backfire as soon as we want to provide functions that both have a configurable LC_TIME and timezone.
- Still limits precision to seconds, even though most modern POSIX interfaces yield struct timespec.
- mktime_z() does need to compute a normalized version of struct tm.

CloudABI's interfaces:
+ Localization remains possible through a single uniform API.
+ By using a full locale_t, implementations could finally tackle the issue that timezone abbreviations are not localized. For example, when using any European timezone in combination with a German LC_TIME, we could print MEZ/MESZ instead of CET/CEST.
+ Nanosecond precision.
- No implementation exists that uses IANA tzcode.

I thought about this a bit more and my suspicion is that implementing CloudABI's interfaces on top of the official TZ code is not hard at all. An implementation could simply encapsulate a timezone_t into its locale_t and implement localtime_l()/mktime_l() as a wrapper around the *_z() functions, fetching the timezone_t from the locale_t.

It is of course also possible to implement it the other way around. NetBSD's interfaces can also be emulated on top of CloudABI's model, by simply defining timezone_t as locale_t.

(0002902)
shware_systems (reporter)
2015-11-12 16:00

Re: "Unfortunately, this was a bad decision, as it turns out locale names can already be suffixed with a @-modifier at the end (POSIX issue 7, section 8.2). I guess we should pick a different character. Any special character would do in my opinion."

In terms of interoperability, '-z' being registered with IETF by OpenGroup or ISO as an extension field is probably the way to go. The trailer would then be of the format '-cityname' or '-tzN', where N is a timezone number west-to-east for countries straddling multiple timezones. Where a country or region designator is not part of the locale name UTC time would be the default. The LC_TIME data would return values like "Europe/Amsterdam" for display purposes for keys like longstdname or longdstname. Keys like abbrevstdname would provide the abbreviated forms, like "MESZ".

Similarly, '-c' should be registered as the generic separator for charmaps, deprecating '@', but that's a separate topic.
(0002903)
kre (reporter)
2015-11-12 20:05

When anything that modified struct tm is done, please also consider
adjusting (or handling in some other way) tm_year from an int to some bigger
type, so it can handle the range of years that modern time_t's can represent.
(0002904)
Guy Harris (reporter)
2015-11-12 22:36
edited on: 2015-11-12 22:39

> The LC_TIME data would return values like "Europe/Amsterdam" for display purposes for keys like longstdname or longdstname.

tzids such as "Europe/Amsterdam" should rarely, if ever, be displayed to humans. In the country to which that tzid applies, the long name for standard time would be "West-Europese standaardtijd" and the long name for DST would be "West-Europese zomertijd", at least if common/main/nl.xml in cldr-28 is to be believed.

And in the C locale, presumably English would be used, yielding "Western European Standard Time" and "Western European Summer Time".

(0002905)
Guy Harris (reporter)
2015-11-12 23:02

If we're going to open up struct tm for additions, we might want to consider two fields that were added, as optional fields, in the tzdb reference implementation, and adopted at least by the later 4BSD and its derivatives, including OS X/iOS/etc.:

        long tm_gmtoff; /* offset from UTC, at the time in question,in seconds */
        char *tm_zone; /* timezone abbreviation, at the time in question */

That way, a converted time will include the offset from UTC at that time (i.e., it would include any DST offset) and the time zone abbreviation at that time, rather than that information having to be dug out of global variables.

We could also consider adding a "char *tm_zonename" to give the long name for the zone - and call the abbreviation field tm_zoneabbr rather than tm_zone (vendors who have tm_zone could add a #define to make it and tm_zoneabbr the same field).

That raises the question of the lifetime of tm_zone. If you convert a time with a given locale_t, and then call freelocale() on that locale_t, is tm_zone still valid? If not, that's a case where you must "code with care"; if so, then you may never be able to free the timezone abbreviation strings from a locale_t, as there's no way to know, in general, when a struct tm is no longer available.
(0002908)
shware_systems (reporter)
2015-11-13 15:08

Re: 2904

I glossed over what might be msgcat-like based in the current locale to support localized or supraregional reporting of names representing another timezone, using items like longstdname as keys. Supraregional names like Central Europe apply to many country tags, so a specific tag value can't be inferred back. For systems that use pick trees as a locale selection UI, that would be a branch label, not a leaf node. The Europe/Amsterdam was simply example drawn from the description as a default display format, that might include chars like '/' not suitable to tags but still Latn script, matching the supplied tag if that locale was made the current one. Other forms of longitude specification are certainly plausible that are compatible with what is allowed in tags, and having localized display names as separate values.

It also glosses over how to generically handle countries that use multiple script types, when just the country is supplied in the tag. What would be most portable then will probably make one ethnic group or another unhappy, as most compromises do. :-)
(0002910)
shware_systems (reporter)
2015-11-13 16:05

Re: 2905

The easy resolution to that is the application supplies buffers the new fields point to. The interface filling the structure would make copies, not point into the locale data directly. If those fields are null when interface is called, then the system can presume the programmer is "coding-with-care" and not freeing the locale until its use of that tm is done. Interfaces or macros _init_tm(tm *, ...) and _done_tm(tm *, [int flags]) could be defined to wrap the malloc(TZ_LNAME_MAX) and malloc(TZ_SNAME_MAX) calls. The ... would be so a previously allocated buffer(s) might get reused, rather than attempt a malloc. If these are static, calling _done_tm() can be skipped entirely.
(0002912)
Guy Harris (reporter)
2015-11-13 16:30

> The Europe/Amsterdam was simply example drawn from the description as a default display format

If by "default display format" you mean "format used in the C locale, and used if the locale doesn't specify a display format, for the long standard time or DST name for the zone", the default display formats, plural, for Europe/Amsterdam should, for recent times, be "Western European Standard Time" and "Western European Summer Time", not "Europe/Amsterdam". (Yes, that would mean that the tzdb should perhaps include the default long names, just as it currently includes the default abbreviations.)

> For systems that use pick trees as a locale selection UI

Systems whose locale selection UI shows tzdb ids are broken. They should, instead, follow the example of, for example, OS X, or even the tzselect script that comes with the tzdb reference implementation.

> It also glosses over how to generically handle countries that use multiple script types, when just the country is supplied in the tag.

The same way that any other text would be handled if you supply a country but not a language in the locale tag, assuming such a locale tag is valid - which I'm not sure it is; this page from the Solaris 11 documentation:

https://docs.oracle.com/cd/E23824_01/html/E26033/glmbx.html [^]

suggests that the country code is optional but the language isn't.
(0002915)
shware_systems (reporter)
2015-11-13 16:44
edited on: 2015-11-13 17:50

By default display format I mean an unambiguous name that can be used as key and may include characters tags won't for potential display. Whether an application chooses to display them or not is up to it. This may have generic subfields which is why I call it a format. Defining what those subfields may be is a separate topic. As long as the value serves that purpose what source it's derived from to match a particular cultural or legislative convention is more a quality of implementation-defined detail. What needs to be explicitly rosterized is the tag values the standard considers valid for combining with a specific ISO-639 country code. If you prefer, tzstdkey and tzdstkey, rather than long/short variants, could be specified as the locale data reference names.

The idea is tag identifiers are limited in charset, the IETF versions being a subset of ASCII/the "C" locale. A less limited equivalent should be accessible as part of the locale data, not try to make it part of the tag. Interfaces that enumerate what prefix subtags might be suitable for a -z subtag value could also be provided.

Yes, only the lang subtag is required. That comment was for the situation when lang and country are provided, but the optional script tag isn't. Where just lang is specified I would expect the country implied to be the one where the language originated, or the modern version at the same geographical location if that coyntry is no longer a political entity.

(0002916)
Guy Harris (reporter)
2015-11-13 16:50

> By default display format I mean an unambiguous name that can be used as key

What does the unambiguous name specify? I.e., if you use it as a key to look up something, what does it return if something is found?
(0002917)
shware_systems (reporter)
2015-11-13 17:53
edited on: 2015-11-13 17:58

It may key into a msgcat database, or other locale data subsections. Whether this returns long names, short names, dst start and end dates, etc. I'm leaving unspecified. Sorry, mouse hiccupped so I had to edit in the remainder.

(0002921)
Guy Harris (reporter)
2015-11-13 18:54

OK, so it's a key, *not* something that would ever be displayed to the user directly (unless the user's trying to debug a problem and needs to know which tzdb zone is being used).

In CLDR, the names may come from a "metazone", a given tzdb zone, identified by a tzid such as Europe/Amsterdam, may have moved from one metazone to another at various points in time, so you might not be able to get long names or short names given only a tzid - you might need to look up a *particular date and time* to find out the long and short names for that particular date/time.
(0002924)
user229
2015-11-13 21:23

If you want to get the Standard/Daylight (standaardtijd/zomertijd, etc) name, you need to also keep the DST flag for the lookup. CLDR doesn't appear to support a single metazone that can have more than two "names"
(0002926)
shware_systems (reporter)
2015-11-13 21:28

Not expected to be displayed, but in the absence of other names being provided by a user-defined locale it would still be a text string that could be displayed as a last resort.

Something like metazone tags would not be keys, or are even references to legitimate locales, technically, suitable for interchange. They may sufficiently define a locale section or sections multiple locales may include using the cldr referencing conventions, but use directly is more an extension behavior to locale() if they only include a few sections, as LC_ALL would fail.
As non-extensions they'd be values such as regionalstdname that various country codes might share the same value for, unless they do get an ISO-639 country identifier, and IMO a user should be prompted for a locale tag that is for a country that is part of that zone if presented such a meta-tag.
(0002927)
user229
2015-11-13 22:02

"They may sufficiently define a locale section or sections multiple locales may include using the cldr referencing conventions"

I don't understand what you mean by this. Are you still saying that the actual time zone (i.e. Eastern vs Central within US) time should be selected by the locale, rather than TZ? I thought we were talking about using the locale solely to provide the native language translation for the *name* of the timezone.

I think the argument that it would cause problems to need to pass two handles to something that needs both locale information and timezone information isn't reasonable. NetBSD already has strftime_lz.
(0002928)
Guy Harris (reporter)
2015-11-13 22:21

> Not expected to be displayed, but in the absence of other names being provided by a user-defined locale it would still be a text string that could be displayed as a last resort.

That's up to the implementation. If we add long time zone names to the UNIX API, whatever mechanisms are used by implementations to determine the default abbreviation should be extended to provide a default long name as well. "Europe/Amsterdam" isn't the name of a time zone, it's the name of a tzdb zone, so it's not appropriate to use as the long name.

> Something like metazone tags would not be keys, or are even references to legitimate locales, technically, suitable for interchange.

No, they're internal details of the CLDR, allowing multiple tzdb zones to share a set of localized time zone names and abbreviations. An implementation that uses the CLDR and the tzdb would, given a tzid and a time, determine, from the CLDR, to which metazone the tzdb zone specified by the tzid belongs, fetch from the CLDR the set of long names and abbreviations for that metazone, and provide the appropriate long name and/or abbreviation depending on whether DST is in effect at that time. The metazone wouldn't be exposed to APIs or to users.
(0002930)
shware_systems (reporter)
2015-11-14 00:19

Re: 2927
I'm looking on it if a locale tag is going to include a zone specifier subtag, the locale data should be sufficient to set TZ and other environment values consistently as part of a call to locale() or setlocale(). An interface like localtime_l(tm *, locale_t) would use the values to map the current locale to the timezone that argument locale uses, for strings. If the current locale is deDE, an argument locale of enUS-z-tz0 would be expected to return in German the equivalent of 'Guam Standard Time' to tm_longname. Use of localtime(tm *) would still reference the TZ variable, which an application could set arbitrarily after the locale is changed. localtime_l(tm *, (locale_t) 0) I'd expect to reference the LC_TZ value, then use TZ directly if that's not set. I haven't looked at the NetBSD code, so that's a guess.
(0002931)
Guy Harris (reporter)
2015-11-14 00:31

> If the current locale is de_DE, an argument locale of en_US-z-tz0 would be expected to return in German the equivalent of 'Guam Standard Time' to tm_longname.

The argument locale begins with en_US, so, if the locale was created with a mklocale() call using LC_ALL_MASK, I'd expect tm_longname to be American English, not German. If the LC_ mask didn't include LC_MESSAGES_MASK, I'd expect it to return German long names.

If you were to specify en_US-z-Europe/Amsterdam and LC_ALL_MASK, I would expect tm_longname to be "Western European Standard Time" or "Western European Summer Time", depending on whether the time specified was during standard time or summer time. If you were to specify nl_NL-z-Europe/Amsterdam and LC_ALL_MASK, I'd expect it to be "West-Europese standaardtijd" or "Western European Summer Time", depending on whether the time specified was during standard time or summer time.
(0002935)
shware_systems (reporter)
2015-11-14 03:43

ty for the clarification. The '/' character is not allowed in IETF tags, so nl-NL-z-Amsterdam would be better. The key value could be Europe/Amsterdam.
(0002936)
Guy Harris (reporter)
2015-11-14 04:08

> so nl-NL-z-Amsterdam would be better. The key value could be Europe/Amsterdam.

And what is the algorithm for turning "z-Amsterdam" into "Europe/Amsterdam"? (Any algorithm that involves looking "z-Amsterdam" in a table would not be good.)

At this point, I'm becoming less convinced that the time zone rules specification belongs in the locale. To quote

    http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html [^]

"A locale is the definition of the subset of a user's environment that depends on language and cultural conventions." The offset from UTC, and the DST rules, don't depend on language, and aren't cultural conventions, they're legal specifications for particular countries or regions.

So I would vote strongly that:

1) we *not* incorporate the time zone offset and DST rule specification into the locale, and *not* introduce a LC_TZ environment variable;

2) we go with something like the NetBSD APIs, but with "struct tm" or its replacement in the new APIs having, at minimum, the abbreviation for the zone at the specified time and the offset from GMT at the specified time as members (rather than using a global variable, which is ugly);

3) we add other information, such as fractions of a second and a long name for the zone at the specified time, to that structure;

as

1) it doesn't require some way to cope with / not being allowed in IETF tags;

2) it doesn't introduce a new environment variable;

3) it implements APIs already in at least one UN*X and in the tzdb reference implementation;

4) it doesn't mix something that has to do with law, not language or culture, into a locale;

which, in my opinion, makes it *cleaner and simpler* than the alternative.

It can handle sub-second precision (presumably the intent is that it be used by strptime() and strftime() - it's not as if we expect the equivalent of localtime() or mktime() or gmtime() to have to deal with it, as time zones and leap seconds don't deal with fractions of a second), as we could provide a structure with them.

It allows localization of time zone abbreviations - the new routines could be defined as returning the appropriate translation of the abbreviation (and full name, if we supply it as well) for the current locale.

We'd still have to deal with the lifetime of the abbreviation (and full name) strings, but both schemes require us to do that.
(0002937)
user229
2015-11-14 04:51

> The argument locale begins with en_US, so, if the locale was created with a mklocale() call using LC_ALL_MASK, I'd expect tm_longname to be American English, not German. If the LC_ mask didn't include LC_MESSAGES_MASK, I'd expect it to return German long names.

Really? Just because they're strings doesn't mean they're messages. Why should time zone names be treated differently than month and weekday names? I'd expect it, and any localized string returned by time-related functions, to be controlled by LC_TIME.

Either way, I think this "timezone LC" stands apart from it, and this is more reason it shouldn't conceptually be a locale contrary to the longstanding practice of using TZ to specify the timezone.

Speaking of TZ, should locales be permitted to provide a localized version of the timezone names for a user-defined timezone? I.e. to "know" that EST5 and EST5EDT mean the America_Eastern metazone, even if it came from TZ=EST5EDT rather than TZ=:America/New_York?
(0002938)
Guy Harris (reporter)
2015-11-14 07:22

> Just because they're strings doesn't mean they're messages.

They're strings used in messages; it seems a bit odd to say "At the tone, the time will be 21:34 West-Europese standaardtijd".

So, other than "it was existing practice", what was the rationale for having multiple LC_ settings, rather than just having LANG - or, if the name bothers people, LOCALE - be a big switch to control all aspects of the locale? In what cases do people set some LC_ variables to override the main locale setting rather than just turning the big switch?

> Speaking of TZ, should locales be permitted to provide a localized version of the timezone names for a user-defined timezone? I.e. to "know" that EST5 and EST5EDT mean the America_Eastern metazone, even if it came from TZ=EST5EDT rather than TZ=:America/New_York?

My inclination would be to say "no", given that section 8 "Environment Variables":

    http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html [^]

says of TZ:

    The expanded format (for all TZ s whose value does not have a <colon> as the first character) is as follows:

stdoffset[dst[offset][,start[/time],end[/time]]]

Where:

std and dst
    Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the designation for the standard (std) or the alternative (dst -such as Daylight Savings Time) timezone. Only std is required; if dst is missing, then the alternative time does not apply in this locale.

    Each of these fields may occur in either of two formats quoted or unquoted:

        * In the quoted form, the first character shall be the <less-than-sign> ( '<' ) character and the last character shall be the <greater-than-sign> ( '>' ) character. All characters between these quoting characters shall be alphanumeric characters from the portable character set in the current locale, the <plus-sign> ( '+' ) character, or the minus-sign ( '-' ) character. The std and dst fields in this case shall not include the quoting characters.

        * In the unquoted form, all characters in these fields shall be alphabetic characters from the portable character set in the current locale.

    The interpretation of these fields is unspecified if either field is less than three bytes (except for the case when dst is missing), more than {TZNAME_MAX} bytes, or if they contain characters other than those specified.

so that the time zone abbreviations come from the string.
(0002943)
shware_systems (reporter)
2015-11-14 16:15

From my perspective:
One reason for having the multiple LC_ sections is most countries do not have a Locales department that is responsible for maintaining all the data and conventions locales represent. Charset is governed by standards in one department, money issues another, time and space metrics another. Having the sections independant allows incremental updates to be provided when one standard maintainer decides a unilateral change is warranted. The standard leaves implementation-defined the naming conventions for such updates, but IETF tags do allow numeric subtags expected to represent 4 digit years. Most implementations just provide an entire new locale definition rather than a smaller update that can be integrated with a prior locale using localedef, if that is desired, or just use as is in scripts with LC_ALL=orig, LC_SECT=update to save disk space.

(Note/Off Topic: Personally, I think to support the above an LC_METADATA section would be useful, cataloging the effective dates and source of the data, narratively and with a reference URL, for each of the other sections and the charmap(s) it may reference. This would allow for error checking of a file's modify date against effective date for 'Are you sure??' prompting, especially for files coming from normally offline archive repositories.)

Another reason is each section is of primary concern to various groups of interfaces, CTYPE for the interfaces in <ctype.h> and <wctype.h>, COLLATE for strcoll(), strxfrm(), etc. so having the separate sections means each can have different entry types geared to the requirements of those interfaces. This is arbitrary, as each entry type could incorporate parts that say "I apply to this structure or interface" directly, but this would make each entry larger.

Last, having them separate does allow for backwards compatible growth. The LC_MESSAGES section is the example of that already in the standard. I expect LC_UNITS (sic) will be the next to make it in, for aiding conversion from metric-to-english and back with language sensitive labeling (e.g. kilometre vs. kilometer, gram vs. gramme).
(0002951)
shware_systems (reporter)
2015-11-15 11:04

Correction, I did mean LC_TIME, not LC_TZ, which would have a subsection possibly labeled LC_TZ that would group the tz related stuff. I was not trying to say there should be a new environment value also. Lookup of values like a key or DST TLA directly would be by an interface, nominally of the prototype

int or errno_t gettzname(char *dst, size_t dstsize, int idx, locale_t lc);
where idx would be #defines like LC_TZKEY, LC_TZSTDLONG, LC_TZSTDREGION, etc. The key could be used to access a tzdb entry of a target locale for translations. How many languages a user-provided locale wanted to include in the localedef to be merged into that database would be up to the file's author. In the absence of a translation a primary value like the LC_TZSTDLONG one would be used.
(0003303)
rhansen (manager)
2016-07-21 16:31
edited on: 2016-07-21 16:32

This was discussed during the 2016-07-21 teleconference. There are three independent feature requests in this single bug report that should be separated into three different bug reports:
  • timegm(): There appears to be widespread existing practice, so this is likely to be accepted in some form depending on the specific wording.
  • locale time zones: This is likely to be rejected for the reasons stated in Note: 0002936 and others.
  • A strftime()-like function with subsecond precision: There appears to be some existing practice of ways to format subsecond precision in a single function, so this has a good chance of being accepted in some form depending on the specific wording.
Note that the Austin Group is not a development body for new material (apart from integration issues arising from the merger of the approved standards that were the Base documents into the revision). If you wish to see new interfaces added to the standard, please follow the process in the "New Work Items" section of http://opengroup.org/austin/docs/austin_sd6.txt. [^]


- Issue History
Date Modified Username Field Change
2015-11-10 10:29 EdSchouten New Issue
2015-11-10 10:29 EdSchouten Status New => Under Review
2015-11-10 10:29 EdSchouten Assigned To => ajosey
2015-11-10 10:29 EdSchouten Name => Ed Schouten
2015-11-10 10:29 EdSchouten Organization => Nuxi
2015-11-10 10:29 EdSchouten Section => <time.h>
2015-11-10 16:38 jsm28 Note Added: 0002898
2015-11-10 17:02 EdSchouten Note Added: 0002899
2015-11-10 17:08 EdSchouten Note Edited: 0002899
2015-11-10 17:34 EdSchouten Note Edited: 0002899
2015-11-12 16:00 shware_systems Note Added: 0002902
2015-11-12 20:05 kre Note Added: 0002903
2015-11-12 22:36 Guy Harris Note Added: 0002904
2015-11-12 22:39 Guy Harris Note Edited: 0002904
2015-11-12 23:02 Guy Harris Note Added: 0002905
2015-11-13 15:08 shware_systems Note Added: 0002908
2015-11-13 16:05 shware_systems Note Added: 0002910
2015-11-13 16:30 Guy Harris Note Added: 0002912
2015-11-13 16:44 shware_systems Note Added: 0002915
2015-11-13 16:50 Guy Harris Note Added: 0002916
2015-11-13 17:50 shware_systems Note Edited: 0002915
2015-11-13 17:53 shware_systems Note Added: 0002917
2015-11-13 17:58 shware_systems Note Edited: 0002917
2015-11-13 18:54 Guy Harris Note Added: 0002921
2015-11-13 21:23 user229 Note Added: 0002924
2015-11-13 21:28 shware_systems Note Added: 0002926
2015-11-13 22:02 user229 Note Added: 0002927
2015-11-13 22:21 Guy Harris Note Added: 0002928
2015-11-14 00:19 shware_systems Note Added: 0002930
2015-11-14 00:31 Guy Harris Note Added: 0002931
2015-11-14 03:43 shware_systems Note Added: 0002935
2015-11-14 04:08 Guy Harris Note Added: 0002936
2015-11-14 04:51 user229 Note Added: 0002937
2015-11-14 07:22 Guy Harris Note Added: 0002938
2015-11-14 16:15 shware_systems Note Added: 0002943
2015-11-15 11:04 shware_systems Note Added: 0002951
2016-07-21 16:31 rhansen Interp Status => ---
2016-07-21 16:31 rhansen Note Added: 0003303
2016-07-21 16:31 rhansen Status Under Review => Closed
2016-07-21 16:31 rhansen Resolution Open => Rejected
2016-07-21 16:32 rhansen Note Edited: 0003303


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker