Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On Wed, 22 Jul 2020, Geoff Clare wrote: Another reason we can't change the required d_t_fmt value for the POSIX (aka C) locale is because it would introduce a conflict with the C standard, which requires (in the strftime() description) that for the C locale %c is equivalent to %a %b %e %T %Y. So if you want to continue arguing for a change to d_t_fmt, you will need to take it up with the C committee. 1 The origin of the format string is POSIX. It was in POSIX for 7 years before it showed up in 'C'. The 'C' defect report #203, requested matching the 'C' locale to the POSIX locale. So for 7 years the content of this format specifier wasn't important to the 'C' Committee and subsequently they only considered it an editorial change: Committee Response Changes were incorporated into the Standard just before printing. This was considered an editorial change by the Committee. 2 The defect concerns the Locale Database and the date utility. Neither of which are defined in 'C' 3 3615-3617 In POSIX.1 the requirements for the POSIX locale are more extensive than the requirements for the C locale as specified in the ISO C standard. 4 There are many other examples of changes going from POSIX to 'C'. So this is the correct place to discuss changing d_t_fmt (which doesn't exist in 'C' either). The 'C' Committee could have made the same arguments against changing their %c definition, which had been unchanged for 7 years in 1999. Instead they saw it as a last minute editorial change. It appears that this Committee may be attaching an unwarranted degree of significance on this locale value and anticipating breakage that likely does not exist. The arguments I have heard against the change are: * every implementation would have to change * applications would potentially break * date(1) does not have to be written in C * no good reason The current draft already forces every implementation to change. Adding three characters to two files would likely be the least invasive change in the current draft. There has been no evidence that any application would break. Any critical date output would likely use a fixed format; rather than %c which can change considerably between locales. No matter what language the date utility is written in, it must implement %c and it must be bound to d_t_fmt. The locale database in XBD is language agnostic. 'no good reason' is a subjective, and rather nebulous, construct that is contrary to a good faith discussion. However, let me try to reframe the 'good reason': * local customs, dialect, and language change * one reason for having a central locale database is to accommodate those changes. Change once, use everywhere. * the date utility's default output string is subject to local customs, dialect, and language changes and needs to be included in the database. * the only way to include date's default output in the POSIX locale's database object is to extend the standard So, a hypothetical implementation has a complete locale database as defined in XBD Chapter 7, with 490 locale objects. In implementing the date utility there are 490 default output format strings comprised of locale dependent specifiers. It does not make since to put these format strings internal to the date utility; the implementor wants them in the locale database with all of the similar date format specifiers. The only locale element that may contain the required date-and-time value is d_t_fmt, but that cannot be used because the POSIX locale blocks it. So the decision is made to extend the locale database. The standard does not accommodate including the date utility's default output string in the locale database. That is the good reason. Earlier I pointed out that a possible reason that %Z was excluded from d_t_fmt is that strptime defined %c, but not %Z. That barrier has been removed in the current draft making it an appropriate opportunity for a coinciding change to d_t_fmt. The IBM i 7.4 POSIX locale sets d_t_fmt to the date utility's default format string (including %Z). Apparently it didn't break anything: https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/nls/rbagsposixexample.htm -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
J William Piggott wrote, on 21 Jul 2020: > > On Mon, 13 Jul 2020, Geoff Clare wrote: > > > J William Piggott wrote, on 12 Jul 2020: > > > > > > On Mon, 6 Jul 2020, Geoff Clare wrote: > > > > > > > There is no way we are going to change the required d_t_fmt value for > > > > the POSIX locale. > > > > > > Why? > > > > Because every implementation would have to change, and all applications > > that rely on the current value would potentially break (depending on > > which fields they use). > > What implementation would have to change? Every implementation. > The locale database assigned > values change on a regular basis. I would not call that an > implementation change. The values in the database for the POSIX locale are mandated by the standard (except for any extensions) and almost never change. As far as the standard is concerned, locale definitions provided with an implementation are part of the implementation. Another reason we can't change the required d_t_fmt value for the POSIX (aka C) locale is because it would introduce a conflict with the C standard, which requires (in the strftime() description) that for the C locale %c is equivalent to %a %b %e %T %Y. So if you want to continue arguing for a change to d_t_fmt, you will need to take it up with the C committee. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
While %Z is part of strftime() in the c2x draft (strptime() is not present at all), it's specification is left as implementation-defined, therefore non-portable enough to be still considered unspecified, for the "C" locale. Additionally, the format %c represents for the "C", and by extension "POSIX", locale is unchanged from C99, and has not added %Z. This would apply to its usage both by strftime() and strptime(), to maintain symmetry, I would think. On Tuesday, July 21, 2020 J William Piggott wrote: On Sun, 12 Jul 2020, shwaresyst wrote: Thank you for replying. > The reason for the disconnect, that I see, is because the %Z modifier > references the TZ environment variable, not a value in a struct tm, adding it > to d_t_fmt would disqualify the definition from being __STD_C__ conforming. > This is one of the areas where the C standard can be considered broken, > leaving Time Zone handling unspecified. As a backwards compatibility matter > changing the tm struct to accommodate time zone info properly is not > indicated, by either standard. It breaks too much code that relies on the > current definition of the tm_year and tm_isdst fields. The people that can do > such a change is the C committee, not POSIX to keep deferring to it, is what > I see more as Geoff's point. The time zone (%Z) isn't unspecified; it's implementation-defined, because it comes from the runtime environment which the C standard avoids. It is expected though, for example, localtime() and friends require time zone and dst information. The only intrastandard reason I can find for %Z to have been excluded from d_t_fmt is that strptime() specified %c, but not %Z. Meaning it would have failed. If that was the only reason for the disconnect, then that roadblock has been removed in the current draft, as strptime() now includes %Z. > On Sunday, July 12, 2020 J William Piggott wrote: > > > On Mon, 6 Jul 2020, Geoff Clare wrote: > >> J William Piggott wrote, on 05 Jul 2020: >>> -- (0004893) geoffclare (manager) - 2020-07-02 10:57 https://austingroupbugs.net/view.php?id=1345#c4893 -- The POSIX locale default date format:%a %b %e %H:%M:%S %Z %Ycontains two pieces of information beyond the minimum of date and time required for other locales: the day name (%a) and the time zone (%Z). Most implementations include these in the default date output for their implementation-provided locales. Since many users would expect to see day name and time zone information in the default date output (particularly if they are used to the traditional behaviour that was standardised for the POSIX locale), as a minimum we should add something to APPLICATION USAGE about this. We should also consider recommending that implementations include them (either via "should" in normative text or a statement in RATIONALE). Here is a suggested set of changes that does the latter... On page 2638 line 85823 section date, add a paragraph to APPLICATION USAGE:Since the default date format for locales other than the POSIX or C locale is not required to include anything beyond the date and time, whereas for the POSIX or C locale it also includes the day name and time zone, it may be necessary to specify a format (or override the locale-selection environment variables) to ensure this information is included when desired. On page 2640 line 85914 section date, add these paragraphs to RATIONALE:Although this standard only requires the default date format, for locales other than the POSIX or C locale, to include the date and time, it is common for implementations to include day name and time zone information as well. (For the POSIX locale this is required, with the day name in %a format at the beginning and the time zone in %Z format before the year.) Implementations are encouraged to include the day name (in %a or %A format) and the time zone (in %Z or %z format) in the default date format for all of the locales they provide. >>> >>> If that rational were applied to the POSIX locale date and time format >>> string >>> the objection would be resolved. >> >> There is no way we are going to change the required d_t_fmt value for >> the POSIX locale. > > Why? > > Has it been discussed with 'we'? Would any of them like to comment on > this please? > > Does anyone have the historical rational for the disconnect between the > POSIX locale's date-and-time format string and the date utility's > default date-and-time format string? That is, why the date(1) default > output contains %Z and LC_TIME d_t_fmt does not. Was this intentional? > If yes, for what reason? > >> -- >> Geoff Clare >> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England >> >> > >
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On Mon, 13 Jul 2020, Eric Blake wrote: On 7/13/20 4:07 AM, Geoff Clare wrote: J William Piggott wrote, on 12 Jul 2020: On Mon, 6 Jul 2020, Geoff Clare wrote: There is no way we are going to change the required d_t_fmt value for the POSIX locale. Why? Because every implementation would have to change, and all applications that rely on the current value would potentially break (depending on which fields they use). We would need a very good reason to make such a change. Has it been discussed with 'we'? Would any of them like to comment on this please? I've been using "we" to refer to the whole Austin Group, i.e. everyone on this mailing list, so yes it has been discussed (in this thread). The three people who's opinions matter are the organisational representatives who would vote on it if it came to that. I'm sure if any of them disagree with what I've said they will comment. Thank you (and Mr Cragun) for replying. To make matters clearer, as one of the organisational reps (Open Group), I'm of the mind that mandating a change to existing practice is undesirable. Standardizing a new format value (especially if there is existing practice to copy from) or adding better documentation to make it clear about the intentional differences between strftime vs. date are both less invasive than a mandatory change to the contents of an existing format value. So I'm concurring with Geoff's handling of the responses so far. I acknowledge the point in principal. In practice, shouldn't each solution be evaluated on its merits? I would argue that adding a new locale element for the date utility is also mandating a change to existing practice. The question should be, which would be less invasive and more beneficial. VALUE ADDED Adding a new locale element has served no purpose other than implementing the POSIX locale. No local custom requires having two date-and-time format strings, one with %Z and one without. Adding %Z to the POSIX locale's d_t_fmt would allow it to be used for the date utility's default output for all locales. It cleans up the locale database and the date utility's code. IMPLEMENTATION DISRUPTION Adding a new LC_TIME element dedicated to the default date utility output could require: * changing hundreds of locale source files * changing hundreds of locale object files * changing the date utility * changing headers * changing library functions * * changing other time related utilities * * assuming it is bound to a format specifier Adding %Z to the POSIX locale d_t_fmt element could require: * adding three characters to one locale source file * adding three characters to one locale object file That could be all that is involved. Implementations that are currently using date_fmt could still do so. Although, the change would allow them to be rid of that troublesome extension if they choose to. I have been searching for potential implementation breakage. I have not found any direct use of d_t_fmt or %c. Changes to assigned values in the locale database should be expected. That is one of the reasons for having it. The glibc locale database has sweeping changes made to it on a regular basis. I believe, updating it from CLDR is semi-automated. Changes to the database should not break implementations. It could break use cases, that is, the parsing of output. However, I have yet to find anything using the format string directly for it's output. Does anyone have an existential example of something that would break if %Z were added to the POSIX locale's d_t_fmt format string? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On Sun, 12 Jul 2020, shwaresyst wrote: Thank you for replying. The reason for the disconnect, that I see, is because the %Z modifier references the TZ environment variable, not a value in a struct tm, adding it to d_t_fmt would disqualify the definition from being __STD_C__ conforming. This is one of the areas where the C standard can be considered broken, leaving Time Zone handling unspecified. As a backwards compatibility matter changing the tm struct to accommodate time zone info properly is not indicated, by either standard. It breaks too much code that relies on the current definition of the tm_year and tm_isdst fields. The people that can do such a change is the C committee, not POSIX to keep deferring to it, is what I see more as Geoff's point. The time zone (%Z) isn't unspecified; it's implementation-defined, because it comes from the runtime environment which the C standard avoids. It is expected though, for example, localtime() and friends require time zone and dst information. The only intrastandard reason I can find for %Z to have been excluded from d_t_fmt is that strptime() specified %c, but not %Z. Meaning it would have failed. If that was the only reason for the disconnect, then that roadblock has been removed in the current draft, as strptime() now includes %Z. On Sunday, July 12, 2020 J William Piggott wrote: On Mon, 6 Jul 2020, Geoff Clare wrote: J William Piggott wrote, on 05 Jul 2020: -- (0004893) geoffclare (manager) - 2020-07-02 10:57 https://austingroupbugs.net/view.php?id=1345#c4893 -- The POSIX locale default date format:%a %b %e %H:%M:%S %Z %Ycontains two pieces of information beyond the minimum of date and time required for other locales: the day name (%a) and the time zone (%Z). Most implementations include these in the default date output for their implementation-provided locales. Since many users would expect to see day name and time zone information in the default date output (particularly if they are used to the traditional behaviour that was standardised for the POSIX locale), as a minimum we should add something to APPLICATION USAGE about this. We should also consider recommending that implementations include them (either via "should" in normative text or a statement in RATIONALE). Here is a suggested set of changes that does the latter... On page 2638 line 85823 section date, add a paragraph to APPLICATION USAGE:Since the default date format for locales other than the POSIX or C locale is not required to include anything beyond the date and time, whereas for the POSIX or C locale it also includes the day name and time zone, it may be necessary to specify a format (or override the locale-selection environment variables) to ensure this information is included when desired. On page 2640 line 85914 section date, add these paragraphs to RATIONALE:Although this standard only requires the default date format, for locales other than the POSIX or C locale, to include the date and time, it is common for implementations to include day name and time zone information as well. (For the POSIX locale this is required, with the day name in %a format at the beginning and the time zone in %Z format before the year.) Implementations are encouraged to include the day name (in %a or %A format) and the time zone (in %Z or %z format) in the default date format for all of the locales they provide. If that rational were applied to the POSIX locale date and time format string the objection would be resolved. There is no way we are going to change the required d_t_fmt value for the POSIX locale. Why? Has it been discussed with 'we'? Would any of them like to comment on this please? Does anyone have the historical rational for the disconnect between the POSIX locale's date-and-time format string and the date utility's default date-and-time format string? That is, why the date(1) default output contains %Z and LC_TIME d_t_fmt does not. Was this intentional? If yes, for what reason? -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On Mon, 13 Jul 2020, Geoff Clare wrote: J William Piggott wrote, on 12 Jul 2020: On Mon, 6 Jul 2020, Geoff Clare wrote: There is no way we are going to change the required d_t_fmt value for the POSIX locale. Why? Because every implementation would have to change, and all applications that rely on the current value would potentially break (depending on which fields they use). What implementation would have to change? The locale database assigned values change on a regular basis. I would not call that an implementation change. I would be surprised if any breakage would happen by adding the time zone to the POSIX locale's date-and-time format string. Do you have an example of something that would break (other than compliance tests)? I have been searching source code and have not found any direct use of d_t_fmt (%c). At one time util-linux hwclock(8) used %c as its default output, but I changed it to ISO 8601. I expected pushback that I had broken something. That was about 5 years ago and, as far as I know, there never have been any complaints. We would need a very good reason to make such a change. Clearly you disagree, but I think this is a very good reason. Has it been discussed with 'we'? Would any of them like to comment on this please? I've been using "we" to refer to the whole Austin Group, i.e. everyone on this mailing list, so yes it has been discussed (in this thread). The three people who's opinions matter are the organisational representatives who would vote on it if it came to that. I'm sure if any of them disagree with what I've said they will comment. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On 7/13/20 4:07 AM, Geoff Clare wrote: J William Piggott wrote, on 12 Jul 2020: On Mon, 6 Jul 2020, Geoff Clare wrote: There is no way we are going to change the required d_t_fmt value for the POSIX locale. Why? Because every implementation would have to change, and all applications that rely on the current value would potentially break (depending on which fields they use). We would need a very good reason to make such a change. Has it been discussed with 'we'? Would any of them like to comment on this please? I've been using "we" to refer to the whole Austin Group, i.e. everyone on this mailing list, so yes it has been discussed (in this thread). The three people who's opinions matter are the organisational representatives who would vote on it if it came to that. I'm sure if any of them disagree with what I've said they will comment. To make matters clearer, as one of the organisational reps (Open Group), I'm of the mind that mandating a change to existing practice is undesirable. Standardizing a new format value (especially if there is existing practice to copy from) or adding better documentation to make it clear about the intentional differences between strftime vs. date are both less invasive than a mandatory change to the contents of an existing format value. So I'm concurring with Geoff's handling of the responses so far. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
J William Piggott wrote, on 12 Jul 2020: > > On Mon, 6 Jul 2020, Geoff Clare wrote: > > > There is no way we are going to change the required d_t_fmt value for > > the POSIX locale. > > Why? Because every implementation would have to change, and all applications that rely on the current value would potentially break (depending on which fields they use). We would need a very good reason to make such a change. > Has it been discussed with 'we'? Would any of them like to comment on > this please? I've been using "we" to refer to the whole Austin Group, i.e. everyone on this mailing list, so yes it has been discussed (in this thread). The three people who's opinions matter are the organisational representatives who would vote on it if it came to that. I'm sure if any of them disagree with what I've said they will comment. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
The reason for the disconnect, that I see, is because the %Z modifier references the TZ environment variable, not a value in a struct tm, adding it to d_t_fmt would disqualify the definition from being __STD_C__ conforming. This is one of the areas where the C standard can be considered broken, leaving Time Zone handling unspecified. As a backwards compatibility matter changing the tm struct to accommodate time zone info properly is not indicated, by either standard. It breaks too much code that relies on the current definition of the tm_year and tm_isdst fields. The people that can do such a change is the C committee, not POSIX to keep deferring to it, is what I see more as Geoff's point. On Sunday, July 12, 2020 J William Piggott wrote: On Mon, 6 Jul 2020, Geoff Clare wrote: > J William Piggott wrote, on 05 Jul 2020: >> >>> -- >>> (0004893) geoffclare (manager) - 2020-07-02 10:57 >>> https://austingroupbugs.net/view.php?id=1345#c4893 >>> -- >>> The POSIX locale default date format:%a %b %e %H:%M:%S %Z >>> %Ycontains two pieces of information beyond the minimum of date and >>> time required for other locales: the day name (%a) and the time zone (%Z). >>> Most implementations include these in the default date output for their >>> implementation-provided locales. >>> >>> Since many users would expect to see day name and time zone information in >>> the default date output (particularly if they are used to the traditional >>> behaviour that was standardised for the POSIX locale), as a minimum we >>> should add something to APPLICATION USAGE about this. We should also >>> consider recommending that implementations include them (either via >>> "should" in normative text or a statement in RATIONALE). Here is a >>> suggested set of changes that does the latter... >>> >>> On page 2638 line 85823 section date, add a paragraph to APPLICATION >>> USAGE:Since the default date format for locales other than the >>> POSIX or C locale is not required to include anything beyond the date and >>> time, whereas for the POSIX or C locale it also includes the day name and >>> time zone, it may be necessary to specify a format (or override the >>> locale-selection environment variables) to ensure this information is >>> included when desired. >>> On page 2640 line 85914 section date, add these paragraphs to >>> RATIONALE:Although this standard only requires the default date >>> format, for locales other than the POSIX or C locale, to include the date >>> and time, it is common for implementations to include day name and time >>> zone information as well. (For the POSIX locale this is required, with the >>> day name in %a format at the beginning and the time zone in %Z format >>> before the year.) Implementations are encouraged to include the day name >>> (in %a or %A format) and the time zone (in %Z or %z format) in the default >>> date format for all of the locales they provide. >> >> If that rational were applied to the POSIX locale date and time format string >> the objection would be resolved. > > There is no way we are going to change the required d_t_fmt value for > the POSIX locale. Why? Has it been discussed with 'we'? Would any of them like to comment on this please? Does anyone have the historical rational for the disconnect between the POSIX locale's date-and-time format string and the date utility's default date-and-time format string? That is, why the date(1) default output contains %Z and LC_TIME d_t_fmt does not. Was this intentional? If yes, for what reason? > -- > Geoff Clare > The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England > >
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On Mon, 6 Jul 2020, Geoff Clare wrote: J William Piggott wrote, on 05 Jul 2020: -- (0004893) geoffclare (manager) - 2020-07-02 10:57 https://austingroupbugs.net/view.php?id=1345#c4893 -- The POSIX locale default date format:%a %b %e %H:%M:%S %Z %Ycontains two pieces of information beyond the minimum of date and time required for other locales: the day name (%a) and the time zone (%Z). Most implementations include these in the default date output for their implementation-provided locales. Since many users would expect to see day name and time zone information in the default date output (particularly if they are used to the traditional behaviour that was standardised for the POSIX locale), as a minimum we should add something to APPLICATION USAGE about this. We should also consider recommending that implementations include them (either via "should" in normative text or a statement in RATIONALE). Here is a suggested set of changes that does the latter... On page 2638 line 85823 section date, add a paragraph to APPLICATION USAGE:Since the default date format for locales other than the POSIX or C locale is not required to include anything beyond the date and time, whereas for the POSIX or C locale it also includes the day name and time zone, it may be necessary to specify a format (or override the locale-selection environment variables) to ensure this information is included when desired. On page 2640 line 85914 section date, add these paragraphs to RATIONALE:Although this standard only requires the default date format, for locales other than the POSIX or C locale, to include the date and time, it is common for implementations to include day name and time zone information as well. (For the POSIX locale this is required, with the day name in %a format at the beginning and the time zone in %Z format before the year.) Implementations are encouraged to include the day name (in %a or %A format) and the time zone (in %Z or %z format) in the default date format for all of the locales they provide. If that rational were applied to the POSIX locale date and time format string the objection would be resolved. There is no way we are going to change the required d_t_fmt value for the POSIX locale. Why? Has it been discussed with 'we'? Would any of them like to comment on this please? Does anyone have the historical rational for the disconnect between the POSIX locale's date-and-time format string and the date utility's default date-and-time format string? That is, why the date(1) default output contains %Z and LC_TIME d_t_fmt does not. Was this intentional? If yes, for what reason? -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
J William Piggott wrote, on 05 Jul 2020: > > > I disagree. The standard defines what each of the conversion > > specifiers is converted to. So the Denmark example demonstrates a > > typical result of a %a conversion, a %d conversion, ..., and a %Z > > conversion for a da_DK locale. > > "what each conversion specifiers is converted to" is implementation > defined. No, it is clearly stated in the standard that %a is converted to the locale's abbreviated weekday name, %d is converted to the day of the month as a decimal number, ..., and %Z is converted to the timezone name. What the abbreviated weekday name is for Denmark in different system's locale definitions is allowed to vary, of course, which is why I used the word "typical" above. > My statement accurately paraphrases those two disjointed requirements. > Your recent suggested addition to the standard states the same language: > | the date > | utility must by default still produce output for that locale that includes > | both the time and the date. > > That is the same as 'locale's appropriate date and time representation' No, they are both required to contain the date and the time, but there is no requirement for them to be represented the same way (and for the POSIX locale they are required not to be represented the same way). > > The standard only requires that by > > default the output includes the date and the time. Using the phrase > > "locale’s appropriate date and time representation" (which is the > > description of the %c format) introduces an unwarranted implication > > that the format used is the same as for the %c conversion. > > It implies that %c *could* be used for the default output. Yes, I have no problem with *could*. > Why are you against adding some clarity to this. I am not against adding clarity. What I am against is your suggestion that the default date utility format be changed to *require* it to be the same as %c. This would force most implementations to change the default date utility format for all of their locales, for no good reason. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On Thu, 2 Jul 2020, Austin Group Bug Tracker wrote: A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1345 == Reported By:j_willie Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1345 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: J William Piggott Organization: User Reference: Section:date Page Number:163, 2634-2638 Line Number:5224-5228, 85673-85823 Interp Status: --- Final Accepted Text: == Date Submitted: 2020-05-24 22:48 UTC Last Modified: 2020-07-02 10:57 UTC == Summary:date(1) default format == -- (0004893) geoffclare (manager) - 2020-07-02 10:57 https://austingroupbugs.net/view.php?id=1345#c4893 -- The POSIX locale default date format:%a %b %e %H:%M:%S %Z %Ycontains two pieces of information beyond the minimum of date and time required for other locales: the day name (%a) and the time zone (%Z). Most implementations include these in the default date output for their implementation-provided locales. Since many users would expect to see day name and time zone information in the default date output (particularly if they are used to the traditional behaviour that was standardised for the POSIX locale), as a minimum we should add something to APPLICATION USAGE about this. We should also consider recommending that implementations include them (either via "should" in normative text or a statement in RATIONALE). Here is a suggested set of changes that does the latter... On page 2638 line 85823 section date, add a paragraph to APPLICATION USAGE:Since the default date format for locales other than the POSIX or C locale is not required to include anything beyond the date and time, whereas for the POSIX or C locale it also includes the day name and time zone, it may be necessary to specify a format (or override the locale-selection environment variables) to ensure this information is included when desired. On page 2640 line 85914 section date, add these paragraphs to RATIONALE:Although this standard only requires the default date format, for locales other than the POSIX or C locale, to include the date and time, it is common for implementations to include day name and time zone information as well. (For the POSIX locale this is required, with the day name in %a format at the beginning and the time zone in %Z format before the year.) Implementations are encouraged to include the day name (in %a or %A format) and the time zone (in %Z or %z format) in the default date format for all of the locales they provide. If that rational were applied to the POSIX locale date and time format string the objection would be resolved. Some implementations have a date_fmt locale keyword (see [xref to XBD 7.3.5]) as an extension, to specify the default date format for each locale. On such implementations, if the localedef utility is used to create a locale that does not have this information, the date utility must by default still produce output for that locale that includes both the time and the date. The above paragraph strikes at the heart of the defect. To implement the standard, the standard must be extended. Many, if not most, existing implementations have interpreted it this way and extended LC_TIME and/or langinfo.h. Sources containing date_fmt: SunOS; Solaris; MacOS; Darwin; glibc; uclibc; freebsd; openbsd; Time Zone Database; coreutils. I am not advocating adding date_fmt as a new LC_TIME keyword, because it has been in glibc for 20 years and has not been useful; except to implement the the POSIX locale albatross. Beyond that, it is just a redundancy of d_t_fmt. The cleanest solution for both the standard, and implementations, is to add %Z to the POSIX d_t_fmt; then d_t_fmt could be used as the date utility's default output for all locales. It is not yet clear to me who invented this extension. The earliest file that I've found containing it is: freebsd v2.1.5 1996-06-04 strftime.c It does appear that Sun invented binding date_fmt to strftime %C, and was burned by the standard for doing so. That is why glibc will not bind it to a format specifier. Consequently, coreutils date(1) accesses date_fmt
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On Tue, 23 Jun 2020, Geoff Clare wrote: J William Piggott wrote, on 22 Jun 2020: On Mon, 22 Jun 2020, Geoff Clare wrote: J William Piggott wrote, on 21 Jun 2020: On Fri, 5 Jun 2020, Geoff Clare wrote: J William Piggott wrote, on 05 Jun 2020: On Tue, 26 May 2020, Geoff Clare wrote: == https://www.austingroupbugs.net/view.php?id=1345 == Summary:date(1) default format ... >8 The several date(1) EXAMPLES seem to support this position. None of the examples show what the output from "date +%c" would be, so I don't see how they support making the default the same as %c. Lets address one step at a time as to why I suggest that. What are these examples demonstrating that is relevant to the standards' definition?: 85867 $ date 85868 Tue Jun 26 09:58:10 PDT 1990 The required output, when no format is specified, in the POSIX locale (presumably with TZ=PST8PDT) 85875 $ LANG=da_DK.iso_8859−1 date 85876 ons 02 okt 1991 15:03:32 CET As per the line above it, this is example output with a locale for Denmark, when no format is specified, on an implementation where the default date and time format for the selected locale is "%a %d %b %Y %T %Z". It does not imply that this is the correct or expected output when using a locale for Denmark, only that this is what you would likely get *if* the default format for the locale is "%a %d %b %Y %T %Z". Nor does it imply anything about how the implementation decides what default format to use for that locale. 85882 $ LANG=De_DE.88591 date 85883 Mi 02.Okt.1991, 15:01:21 MEZ Likewise for Germany if the default format is "%a %d. %h. %Y, %T %Z". 85888 $ LANG=Fr_FR.88591 date 85889 Mer 02 oct 1991 MET 15:03:32 Likewise for France if the default format is "%a %d %h %Y %Z %T". So, for examples 2, 3, and 4 your answer to my question is: nothing? No, not nothing. Each one demonstrates what the output would be on a system that has a particular default date format associated with the locale it uses. The question contained: relevant to the standards' definition. Your reply was, and continues to be, relevant to an imaginary implementation. So by refusing to answer the question, your answer is that they demonstrate nothing relevant to the standard. I disagree. The standard defines what each of the conversion specifiers is converted to. So the Denmark example demonstrates a typical result of a %a conversion, a %d conversion, ..., and a %Z conversion for a da_DK locale. "what each conversion specifiers is converted to" is implementation defined. So again, that does not demonstrate anything relevant to the date utility's specification (even more so in the current draft which defers all formatting to strftime). Are not the examples demonstrating relevant date utility specification requirments as follows: 85674 By default, the current date and time shall be written. No, because the examples state a particular default format. Which is required to be date and time. Which is what the particular demonstration format is. Which is the only thing the particular demonstration format can be, or it would violate the standard. Which is what the result shows. So yes, they do demonstrate: By default, the current date and time shall be written. The stated default date format is a condition - a prerequisite for the output to be what is shown. I don't see how that can be construed as a demonstration of requirements on what default date formats must contain. I do not understand why you are so focused on what the output looks like, or what the format string is. For the most part that is implementation defined for non-POSIX locales. However, the standard does require some restrictions on the 'default' output in that it must be 'date and time'. The prerequisite format string must follow that restriction. The examples do demonstrate that requirement. They have to, or the examples would be violating the standard. However, I do not need the examples to make my point; as it is clearly defined within the standard. 85674 By default, the current date and time shall be written. 85785 The following environment variables shall affect the execution of date: Those two requirements can be written more succinctly as the default output shall be the: locale’s appropriate date and time representation. No, that is not the same at all. My statement accurately paraphrases those two disjointed requirements. Your recent suggested addition to the standard states the same language: | the date | utility must by default still produce output for that locale that includes | both the time and the date. That is the same as 'locale's appropriate date and time representation' The standard only requires that by default the output includes the date and the time. Using the phrase "locale’s appropriate date and
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
J William Piggott wrote, on 22 Jun 2020: > > On Mon, 22 Jun 2020, Geoff Clare wrote: > > >J William Piggott wrote, on 21 Jun 2020: > >> > >>On Fri, 5 Jun 2020, Geoff Clare wrote: > >> > >>>J William Piggott wrote, on 05 Jun 2020: > > On Tue, 26 May 2020, Geoff Clare wrote: > > >>== > >>https://www.austingroupbugs.net/view.php?id=1345 > >>== > > > >>Summary:date(1) default format > > ... >8 > > > > >> The several date(1) EXAMPLES seem to support this position. > > > >None of the examples show what the output from "date +%c" would be, > >so I don't see how they support making the default the same as %c. > > > > Lets address one step at a time as to why I suggest that. > > What are these examples demonstrating that is relevant to the standards' > definition?: > > 85867 $ date > 85868 Tue Jun 26 09:58:10 PDT 1990 > >>> > >>>The required output, when no format is specified, in the POSIX locale > >>>(presumably with TZ=PST8PDT) > >>> > 85875 $ LANG=da_DK.iso_8859−1 date > 85876 ons 02 okt 1991 15:03:32 CET > >>> > >>>As per the line above it, this is example output with a locale for > >>>Denmark, when no format is specified, on an implementation where the > >>>default date and time format for the selected locale is > >>>"%a %d %b %Y %T %Z". > >>> > >>>It does not imply that this is the correct or expected output when > >>>using a locale for Denmark, only that this is what you would likely > >>>get *if* the default format for the locale is "%a %d %b %Y %T %Z". > >>> > >>>Nor does it imply anything about how the implementation decides > >>>what default format to use for that locale. > >>> > 85882 $ LANG=De_DE.88591 date > 85883 Mi 02.Okt.1991, 15:01:21 MEZ > >>> > >>>Likewise for Germany if the default format is "%a %d. %h. %Y, %T %Z". > >>> > 85888 $ LANG=Fr_FR.88591 date > 85889 Mer 02 oct 1991 MET 15:03:32 > >>> > >>>Likewise for France if the default format is "%a %d %h %Y %Z %T". > >> > >>So, for examples 2, 3, and 4 your answer to my question is: nothing? > > > >No, not nothing. Each one demonstrates what the output would be on a > >system that has a particular default date format associated with the > >locale it uses. > > The question contained: relevant to the standards' definition. > Your reply was, and continues to be, relevant to an imaginary > implementation. So by refusing to answer the question, your answer is > that they demonstrate nothing relevant to the standard. I disagree. The standard defines what each of the conversion specifiers is converted to. So the Denmark example demonstrates a typical result of a %a conversion, a %d conversion, ..., and a %Z conversion for a da_DK locale. > > >>Are not the examples demonstrating relevant date utility specification > >>requirments as follows: > >> > >>85674 By default, the current date and time shall be written. > > > >No, because the examples state a particular default format. > > Which is required to be date and time. Which is what the particular > demonstration format is. Which is the only thing the particular > demonstration format can be, or it would violate the standard. Which is > what the result shows. So yes, they do demonstrate: By default, the > current date and time shall be written. The stated default date format is a condition - a prerequisite for the output to be what is shown. I don't see how that can be construed as a demonstration of requirements on what default date formats must contain. > However, I do not need the examples to make my point; as it is clearly > defined within the standard. > > 85674 By default, the current date and time shall be written. > 85785 The following environment variables shall affect the execution of date: > > Those two requirements can be written more succinctly as the default > output shall be the: locale’s appropriate date and time representation. No, that is not the same at all. The standard only requires that by default the output includes the date and the time. Using the phrase "locale’s appropriate date and time representation" (which is the description of the %c format) introduces an unwarranted implication that the format used is the same as for the %c conversion. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On Sun, 21 Jun 2020, shwaresyst wrote: Re: Are not the examples demonstrating relevant date utility specification requirments as follows: No, they are examples of how the various specified elements can produce output reflecting various locale LC_TIME settings, that's all. The actual format string is still an unspecified implementation election, not requirement. The Description leaves open an implementation can elect to use %c for all locales, but to keep backwards compatibility can't make this a requirement. It was not my intent to require the use of %c. The recent addition to the draft states formatting 'as if by strftime()', so use of its specifiers would also be optional. I do acknowledge that my original Desired Action language does make it required and needs to be changed. My intent was to: * clarify that the default output is the locale's date and time * shine light on a practical implementation path within the standard's framework by use of strftime() %c Perhaps something like: STDOUT When no formatting operand is specified, the output in the POSIX locale shall be equivalent to specifying: date "+%a %b %e %H:%M:%S %Z %Y"; for Non-POSIX locales the output shall be the locale's date and time as if by strftime() %c. (there is a second half to the defect where I attempt to get the POSIX STDOUT and d_t_fmt in alignment; but lets discuss one piece at a time) What can be done, if someone wants to implement it, is add a switch, say "-c", that does use %c instead of any default, and then portable code can be written that examines LC_TIME data for guiding a parse of the utility's output. Then an enhancement request to require that new switch can be drafted. On Sunday, June 21, 2020 J William Piggott wrote: On Fri, 5 Jun 2020, Geoff Clare wrote: J William Piggott wrote, on 05 Jun 2020: On Tue, 26 May 2020, Geoff Clare wrote: == https://www.austingroupbugs.net/view.php?id=1345 == Summary: date(1) default format ... >8 The several date(1) EXAMPLES seem to support this position. None of the examples show what the output from "date +%c" would be, so I don't see how they support making the default the same as %c. Lets address one step at a time as to why I suggest that. What are these examples demonstrating that is relevant to the standards' definition?: 85867 $ date 85868 Tue Jun 26 09:58:10 PDT 1990 The required output, when no format is specified, in the POSIX locale (presumably with TZ=PST8PDT) 85875 $ LANG=da_DK.iso_8859−1 date 85876 ons 02 okt 1991 15:03:32 CET As per the line above it, this is example output with a locale for Denmark, when no format is specified, on an implementation where the default date and time format for the selected locale is "%a %d %b %Y %T %Z". It does not imply that this is the correct or expected output when using a locale for Denmark, only that this is what you would likely get *if* the default format for the locale is "%a %d %b %Y %T %Z". Nor does it imply anything about how the implementation decides what default format to use for that locale. 85882 $ LANG=De_DE.88591 date 85883 Mi 02.Okt.1991, 15:01:21 MEZ Likewise for Germany if the default format is "%a %d. %h. %Y, %T %Z". 85888 $ LANG=Fr_FR.88591 date 85889 Mer 02 oct 1991 MET 15:03:32 Likewise for France if the default format is "%a %d %h %Y %Z %T". So, for examples 2, 3, and 4 your answer to my question is: nothing? Are not the examples demonstrating relevant date utility specification requirments as follows: 85674 By default, the current date and time shall be written. 85785 The following environment variables shall affect the execution of date: 85786 LANG -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On Mon, 22 Jun 2020, Geoff Clare wrote: J William Piggott wrote, on 21 Jun 2020: On Fri, 5 Jun 2020, Geoff Clare wrote: J William Piggott wrote, on 05 Jun 2020: On Tue, 26 May 2020, Geoff Clare wrote: == https://www.austingroupbugs.net/view.php?id=1345 == Summary:date(1) default format ... >8 The several date(1) EXAMPLES seem to support this position. None of the examples show what the output from "date +%c" would be, so I don't see how they support making the default the same as %c. Lets address one step at a time as to why I suggest that. What are these examples demonstrating that is relevant to the standards' definition?: 85867 $ date 85868 Tue Jun 26 09:58:10 PDT 1990 The required output, when no format is specified, in the POSIX locale (presumably with TZ=PST8PDT) 85875 $ LANG=da_DK.iso_8859−1 date 85876 ons 02 okt 1991 15:03:32 CET As per the line above it, this is example output with a locale for Denmark, when no format is specified, on an implementation where the default date and time format for the selected locale is "%a %d %b %Y %T %Z". It does not imply that this is the correct or expected output when using a locale for Denmark, only that this is what you would likely get *if* the default format for the locale is "%a %d %b %Y %T %Z". Nor does it imply anything about how the implementation decides what default format to use for that locale. 85882 $ LANG=De_DE.88591 date 85883 Mi 02.Okt.1991, 15:01:21 MEZ Likewise for Germany if the default format is "%a %d. %h. %Y, %T %Z". 85888 $ LANG=Fr_FR.88591 date 85889 Mer 02 oct 1991 MET 15:03:32 Likewise for France if the default format is "%a %d %h %Y %Z %T". So, for examples 2, 3, and 4 your answer to my question is: nothing? No, not nothing. Each one demonstrates what the output would be on a system that has a particular default date format associated with the locale it uses. The question contained: relevant to the standards' definition. Your reply was, and continues to be, relevant to an imaginary implementation. So by refusing to answer the question, your answer is that they demonstrate nothing relevant to the standard. Are not the examples demonstrating relevant date utility specification requirments as follows: 85674 By default, the current date and time shall be written. No, because the examples state a particular default format. Which is required to be date and time. Which is what the particular demonstration format is. Which is the only thing the particular demonstration format can be, or it would violate the standard. Which is what the result shows. So yes, they do demonstrate: By default, the current date and time shall be written. The formats stated are, of course, ones that meet the requirement that they include both the date and the time, but that's not what is being demonstrated. Of course that's what's being demonstrated. You don't get to pick and choose what an example demonstrates. It is what it is. 85785 The following environment variables shall affect the execution of date: 85786 LANG I suppose you could think of that as being part of what they are demonstrating, but I would say that the examples just naturally assume that the locale selection mechanism works correctly. It has nothing to do with what I think. It is what they demonstrate relevant to the standard. If those example are intended to demonstrate only what some unknown implementation 'likely', '*if*', may, or may not do. Then they serve no purpose within the standard. Examples are to clarify the subject. The subject is the date utility standard specification. They do demonstrate, and clarify, what I've stated as relevant to the standard. However, I do not need the examples to make my point; as it is clearly defined within the standard. 85674 By default, the current date and time shall be written. 85785 The following environment variables shall affect the execution of date: Those two requirements can be written more succinctly as the default output shall be the: locale’s appropriate date and time representation. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
J William Piggott wrote, on 21 Jun 2020: > > On Fri, 5 Jun 2020, Geoff Clare wrote: > > >J William Piggott wrote, on 05 Jun 2020: > >> > >> On Tue, 26 May 2020, Geoff Clare wrote: > >> > >> >>== > >> >>https://www.austingroupbugs.net/view.php?id=1345 > >> >>== > >> > > >> >>Summary:date(1) default format > >> > >> ... >8 > >> > >> > > >> >> The several date(1) EXAMPLES seem to support this position. > >> > > >> >None of the examples show what the output from "date +%c" would be, > >> >so I don't see how they support making the default the same as %c. > >> > > >> > >> Lets address one step at a time as to why I suggest that. > >> > >> What are these examples demonstrating that is relevant to the standards' > >> definition?: > >> > >> 85867 $ date > >> 85868 Tue Jun 26 09:58:10 PDT 1990 > > > >The required output, when no format is specified, in the POSIX locale > >(presumably with TZ=PST8PDT) > > > >> 85875 $ LANG=da_DK.iso_8859â1 date > >> 85876 ons 02 okt 1991 15:03:32 CET > > > >As per the line above it, this is example output with a locale for > >Denmark, when no format is specified, on an implementation where the > >default date and time format for the selected locale is > >"%a %d %b %Y %T %Z". > > > >It does not imply that this is the correct or expected output when > >using a locale for Denmark, only that this is what you would likely > >get *if* the default format for the locale is "%a %d %b %Y %T %Z". > > > >Nor does it imply anything about how the implementation decides > >what default format to use for that locale. > > > >> 85882 $ LANG=De_DE.88591 date > >> 85883 Mi 02.Okt.1991, 15:01:21 MEZ > > > >Likewise for Germany if the default format is "%a %d. %h. %Y, %T %Z". > > > >> 85888 $ LANG=Fr_FR.88591 date > >> 85889 Mer 02 oct 1991 MET 15:03:32 > > > >Likewise for France if the default format is "%a %d %h %Y %Z %T". > > So, for examples 2, 3, and 4 your answer to my question is: nothing? No, not nothing. Each one demonstrates what the output would be on a system that has a particular default date format associated with the locale it uses. > Are not the examples demonstrating relevant date utility specification > requirments as follows: > > 85674 By default, the current date and time shall be written. No, because the examples state a particular default format. The formats stated are, of course, ones that meet the requirement that they include both the date and the time, but that's not what is being demonstrated. > 85785 The following environment variables shall affect the execution of date: > 85786 LANG I suppose you could think of that as being part of what they are demonstrating, but I would say that the examples just naturally assume that the locale selection mechanism works correctly. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
Re: Are not the examples demonstrating relevant date utility specification requirments as follows: No, they are examples of how the various specified elements can produce output reflecting various locale LC_TIME settings, that's all. The actual format string is still an unspecified implementation election, not requirement. The Description leaves open an implementation can elect to use %c for all locales, but to keep backwards compatibility can't make this a requirement. What can be done, if someone wants to implement it, is add a switch, say "-c", that does use %c instead of any default, and then portable code can be written that examines LC_TIME data for guiding a parse of the utility's output. Then an enhancement request to require that new switch can be drafted. On Sunday, June 21, 2020 J William Piggott wrote: On Fri, 5 Jun 2020, Geoff Clare wrote: > J William Piggott wrote, on 05 Jun 2020: > > > > On Tue, 26 May 2020, Geoff Clare wrote: > > > > >>== > > >>https://www.austingroupbugs.net/view.php?id=1345 > > >>== > > > > > >>Summary: date(1) default format > > > > ... >8 > > > > > > > >> The several date(1) EXAMPLES seem to support this position. > > > > > >None of the examples show what the output from "date +%c" would be, > > >so I don't see how they support making the default the same as %c. > > > > > > > Lets address one step at a time as to why I suggest that. > > > > What are these examples demonstrating that is relevant to the standards' > > definition?: > > > > 85867 $ date > > 85868 Tue Jun 26 09:58:10 PDT 1990 > > The required output, when no format is specified, in the POSIX locale > (presumably with TZ=PST8PDT) > > > 85875 $ LANG=da_DK.iso_8859−1 date > > 85876 ons 02 okt 1991 15:03:32 CET > > As per the line above it, this is example output with a locale for > Denmark, when no format is specified, on an implementation where the > default date and time format for the selected locale is > "%a %d %b %Y %T %Z". > > It does not imply that this is the correct or expected output when > using a locale for Denmark, only that this is what you would likely > get *if* the default format for the locale is "%a %d %b %Y %T %Z". > > Nor does it imply anything about how the implementation decides > what default format to use for that locale. > > > 85882 $ LANG=De_DE.88591 date > > 85883 Mi 02.Okt.1991, 15:01:21 MEZ > > Likewise for Germany if the default format is "%a %d. %h. %Y, %T %Z". > > > 85888 $ LANG=Fr_FR.88591 date > > 85889 Mer 02 oct 1991 MET 15:03:32 > > Likewise for France if the default format is "%a %d %h %Y %Z %T". So, for examples 2, 3, and 4 your answer to my question is: nothing? Are not the examples demonstrating relevant date utility specification requirments as follows: 85674 By default, the current date and time shall be written. 85785 The following environment variables shall affect the execution of date: 85786 LANG > -- > Geoff Clare > The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England > >
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On Fri, 5 Jun 2020, Geoff Clare wrote: J William Piggott wrote, on 05 Jun 2020: > > On Tue, 26 May 2020, Geoff Clare wrote: > > >>== > >>https://www.austingroupbugs.net/view.php?id=1345 > >>== > > > >>Summary:date(1) default format > > ... >8 > > > > >> The several date(1) EXAMPLES seem to support this position. > > > >None of the examples show what the output from "date +%c" would be, > >so I don't see how they support making the default the same as %c. > > > > Lets address one step at a time as to why I suggest that. > > What are these examples demonstrating that is relevant to the standards' > definition?: > > 85867 $ date > 85868 Tue Jun 26 09:58:10 PDT 1990 The required output, when no format is specified, in the POSIX locale (presumably with TZ=PST8PDT) > 85875 $ LANG=da_DK.iso_8859â1 date > 85876 ons 02 okt 1991 15:03:32 CET As per the line above it, this is example output with a locale for Denmark, when no format is specified, on an implementation where the default date and time format for the selected locale is "%a %d %b %Y %T %Z". It does not imply that this is the correct or expected output when using a locale for Denmark, only that this is what you would likely get *if* the default format for the locale is "%a %d %b %Y %T %Z". Nor does it imply anything about how the implementation decides what default format to use for that locale. > 85882 $ LANG=De_DE.88591 date > 85883 Mi 02.Okt.1991, 15:01:21 MEZ Likewise for Germany if the default format is "%a %d. %h. %Y, %T %Z". > 85888 $ LANG=Fr_FR.88591 date > 85889 Mer 02 oct 1991 MET 15:03:32 Likewise for France if the default format is "%a %d %h %Y %Z %T". So, for examples 2, 3, and 4 your answer to my question is: nothing? Are not the examples demonstrating relevant date utility specification requirments as follows: 85674 By default, the current date and time shall be written. 85785 The following environment variables shall affect the execution of date: 85786 LANG -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
There is also the POSIX locale is a superset of the C locale as defined by the C standard, because it requires support of the Portable Character Set, which has more chars than C requires, and has the LC_MESSAGES category; as primary differences. On Wednesday, June 10, 2020 Joerg Schilling wrote: "Schwarz, Konrad" wrote: > Hmm, isn't it also so that applications can make more assumptions about the > input/output of utilities? Defining a POSIX locale > for the sole purpose of enabling testing the compliance of said locale seems > very redundant. And actually, I'm pretty > sure the POSIX locale was defined to behave as traditional, non-locale > enabled Unix, to make it possible to have locale support > as a differentiating feature. In the late 1990s, many US Solaris users have been confused as the US English locale has been introduced past European locales and behaved different from the C locale they have been used to use before. Jörg -- EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On 6/8/2020 2:39 AM, Schwarz, Konrad wrote: -Original Message- From: Larry Dwyer The purpose of the POSIX locale is mandatory so that a conformance suite can be developed for the purpose of testing and branding a manufacturer's system for POSIX conformance (period). Hmm, isn't it also so that applications can make more assumptions about the input/output of utilities? Defining a POSIX locale for the sole purpose of enabling testing the compliance of said locale seems very redundant. And actually, I'm pretty sure the POSIX locale was defined to behave as traditional, non-locale enabled Unix, to make it possible to have locale support as a differentiating feature. Not necessarily. When Native Language (NL) and Internationalization (I18N) began appearing as a requirement in order to sell into countries that had enough influence to insist they did not need to teach their citizens English (and American English at that) in order to use computers from "foreign" companies, the US computer industry realized the manufacturers needed to adapt their products to the market, or "non-foreign" companies would displace sales volume the "foreign" companies already achieved. In the 70's I was employed by HP and "we" were already developing NL for all of our computers and data terminals so we could retain the significant profits we had developed in Europe and Japan. After IEEE 1003.1 (POSIX) was published in 1988, the members that went on to develop IEEE 1003.2 were reminded that NL, I18N and Localization had more affect on commands (1003.2) than the kernel and libc (1003.1). Very expensive test suites were simultaneously being developed in Washington D.C. (FIPS), Boston (Open Software Foundation AES), New Jersey (AT SVVS) and the UK (X/Open XPG). In light of the development of the Localization Standard, test developers were asking what the correct response from "date" was so that it could be tested even if the test was run in Germany versus Washington D.C. versus New Jersey versus Boston. The POSIX committee invented the POSIX Locale and made it mandatory. If a company wanted to claim conformance to the POSIX Standard, they had to implement the POSIX locale. All other locales were neither mandatory nor defined by POSIX. There was no such thing as "traditional, non-locale enabled UNIX". There was 7th Edition, 32V, Plan-9, System 3, System 5, BSD, MIT-68K, HPUX, AIX, Solaris and about 15 or more other UNIX variations, all different. For our potential "UNIX" customer pool, it was worse than being stuck in a maze of twisty passages, all different. That is why, at a 1983 USENIX conference in Dallas, Texas, an ad hoc committee was formed to ponder how the "UNIX" industry could avoid fragmenting itself into oblivion. From this meeting, POSIX was born. As it turns out, POSIX was not a "traditional UNIX". Even AT didn't have a traditional UNIX. Cheers, Larry
RE: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
> -Original Message- > From: Larry Dwyer > The purpose of the POSIX locale is mandatory so that a conformance suite can > be developed for the purpose of testing and branding a > manufacturer's system for POSIX conformance (period). Hmm, isn't it also so that applications can make more assumptions about the input/output of utilities? Defining a POSIX locale for the sole purpose of enabling testing the compliance of said locale seems very redundant. And actually, I'm pretty sure the POSIX locale was defined to behave as traditional, non-locale enabled Unix, to make it possible to have locale support as a differentiating feature.
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
Hi Willie, The example sections of the standard are "informative" not "normative". They do not affect conformance to the "standard". You will find the definition of "informative" and "normative" within the Single UNIX Specification. In this case, these examples demonstrate that, if the user changes the locale, the default output of "date" may change (in a way not defined by the Standard). The non-POSIX locales are developed by customs within a country and need not be supported on any POSIX conforming system. Which locales a computer manufacture chooses to support is a marketing decision. The purpose of the POSIX locale is mandatory so that a conformance suite can be developed for the purpose of testing and branding a manufacturer's system for POSIX conformance (period). In a locale other than the POSIX locale, "date +%c" will print whatever the locale definition file describes for the local custom that was selected by the user. The normative portion of the IEEE 1003 Standard is silent about what these local customs must be. In my opinion, "date" is not broken. Cheers, Larry On 6/5/2020 8:58 AM, J William Piggott wrote: On Tue, 26 May 2020, Geoff Clare wrote: == https://www.austingroupbugs.net/view.php?id=1345 == Summary: date(1) default format ... >8 The several date(1) EXAMPLES seem to support this position. None of the examples show what the output from "date +%c" would be, so I don't see how they support making the default the same as %c. Lets address one step at a time as to why I suggest that. What are these examples demonstrating that is relevant to the standards' definition?: 85867 $ date 85868 Tue Jun 26 09:58:10 PDT 1990 85875 $ LANG=da_DK.iso_8859−1 date 85876 ons 02 okt 1991 15:03:32 CET 85882 $ LANG=De_DE.88591 date 85883 Mi 02.Okt.1991, 15:01:21 MEZ 85888 $ LANG=Fr_FR.88591 date 85889 Mer 02 oct 1991 MET 15:03:32 Willie -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
J William Piggott wrote, on 05 Jun 2020: > > On Tue, 26 May 2020, Geoff Clare wrote: > > >>== > >>https://www.austingroupbugs.net/view.php?id=1345 > >>== > > > >>Summary:date(1) default format > > ... >8 > > > > >> The several date(1) EXAMPLES seem to support this position. > > > >None of the examples show what the output from "date +%c" would be, > >so I don't see how they support making the default the same as %c. > > > > Lets address one step at a time as to why I suggest that. > > What are these examples demonstrating that is relevant to the standards' > definition?: > > 85867 $ date > 85868 Tue Jun 26 09:58:10 PDT 1990 The required output, when no format is specified, in the POSIX locale (presumably with TZ=PST8PDT) > 85875 $ LANG=da_DK.iso_8859−1 date > 85876 ons 02 okt 1991 15:03:32 CET As per the line above it, this is example output with a locale for Denmark, when no format is specified, on an implementation where the default date and time format for the selected locale is "%a %d %b %Y %T %Z". It does not imply that this is the correct or expected output when using a locale for Denmark, only that this is what you would likely get *if* the default format for the locale is "%a %d %b %Y %T %Z". Nor does it imply anything about how the implementation decides what default format to use for that locale. > 85882 $ LANG=De_DE.88591 date > 85883 Mi 02.Okt.1991, 15:01:21 MEZ Likewise for Germany if the default format is "%a %d. %h. %Y, %T %Z". > 85888 $ LANG=Fr_FR.88591 date > 85889 Mer 02 oct 1991 MET 15:03:32 Likewise for France if the default format is "%a %d %h %Y %Z %T". -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On Tue, 26 May 2020, Geoff Clare wrote: == https://www.austingroupbugs.net/view.php?id=1345 == Summary:date(1) default format ... >8 The several date(1) EXAMPLES seem to support this position. None of the examples show what the output from "date +%c" would be, so I don't see how they support making the default the same as %c. Lets address one step at a time as to why I suggest that. What are these examples demonstrating that is relevant to the standards' definition?: 85867 $ date 85868 Tue Jun 26 09:58:10 PDT 1990 85875 $ LANG=da_DK.iso_8859−1 date 85876 ons 02 okt 1991 15:03:32 CET 85882 $ LANG=De_DE.88591 date 85883 Mi 02.Okt.1991, 15:01:21 MEZ 85888 $ LANG=Fr_FR.88591 date 85889 Mer 02 oct 1991 MET 15:03:32 Willie -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
Hi Alan, Thanks for your rapid and detailed response. I appreciate that you made the extra effort to included the SCCS comments. I should be able to trigger a resolution to this defect report after I have an opportunity to close with the originator. Cheers, Larry On 5/29/2020 2:02 PM, Alan Coopersmith wrote: On 5/28/20 10:03 PM, Larry Dwyer wrote: To anyone at Oracle Inc. on this mailing list: I have gone through my library and found only one reference to date_fmt. It is in the proceedings of the Tenth International Unicode Conference. It is in an informative discussion about locale performance as measured on Solaris. It is in the LC_TIME locale subgroup, but I don't think it is in a base header file (it seems to me to be a "localized" header file). Can someone at Oracle contact me so "we" can determine when/why/for-whom it was added to Solaris. The header file it was extracted from and placed into the proceedings is copyright Sun Microsystems 1996. It is documented in our locale(7) man page for Solaris 11.4, or locale(5) for earlier Solaris releases going back to 2.6: https://docs.oracle.com/cd/E88353_01/html/E37853/locale-7.html https://docs.oracle.com/cd/E19504-01/802-5747-05/802-5747-05.pdf Our localedef.h header marks it as a Solaris extension in struct _LC_time_t. Old sccs files show it was added in 1996, as part of the changes to handle the differing definitions of %C in strftime for XPG4 vs. previous Solaris behavior in the new code being brought in from COSE, with the commit comment of: 1250363 - %c should default to XPG3 format, but use XPG4 format in XPG4 environment (if __xpg4 is on); %C should default to Solaris behavior (default date format), but exhibit XPG4 behavior (century number) in XPG4 environment. (I was not at Sun in 1996, so can only offer what I can still find recorded from that time, not personal insight.)
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On 5/28/20 10:03 PM, Larry Dwyer wrote: To anyone at Oracle Inc. on this mailing list: I have gone through my library and found only one reference to date_fmt. It is in the proceedings of the Tenth International Unicode Conference. It is in an informative discussion about locale performance as measured on Solaris. It is in the LC_TIME locale subgroup, but I don't think it is in a base header file (it seems to me to be a "localized" header file). Can someone at Oracle contact me so "we" can determine when/why/for-whom it was added to Solaris. The header file it was extracted from and placed into the proceedings is copyright Sun Microsystems 1996. It is documented in our locale(7) man page for Solaris 11.4, or locale(5) for earlier Solaris releases going back to 2.6: https://docs.oracle.com/cd/E88353_01/html/E37853/locale-7.html https://docs.oracle.com/cd/E19504-01/802-5747-05/802-5747-05.pdf Our localedef.h header marks it as a Solaris extension in struct _LC_time_t. Old sccs files show it was added in 1996, as part of the changes to handle the differing definitions of %C in strftime for XPG4 vs. previous Solaris behavior in the new code being brought in from COSE, with the commit comment of: 1250363 - %c should default to XPG3 format, but use XPG4 format in XPG4 environment (if __xpg4 is on); %C should default to Solaris behavior (default date format), but exhibit XPG4 behavior (century number) in XPG4 environment. (I was not at Sun in 1996, so can only offer what I can still find recorded from that time, not personal insight.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
To anyone at Oracle Inc. on this mailing list: I have gone through my library and found only one reference to date_fmt. It is in the proceedings of the Tenth International Unicode Conference. It is in an informative discussion about locale performance as measured on Solaris. It is in the LC_TIME locale subgroup, but I don't think it is in a base header file (it seems to me to be a "localized" header file). Can someone at Oracle contact me so "we" can determine when/why/for-whom it was added to Solaris. The header file it was extracted from and placed into the proceedings is copyright Sun Microsystems 1996. I have scanned most of the HP-UX releases in my document library (7.0, 8.04, 9.0, 10.0, 11.0) and found no references to date_fmt in any of the base manuals. It might be helpful if IBM could check on this too. LC_TIME...date_fmt. It might be helpful if someone who is familiar with Linux could check too. You can reply to this mailing list or directly to me. Thanks, Larry
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
Hi Geoff, I was already working with William to research XPG[234] behind the scenes. Unfortunately, my copies of the various standards were in such condition and organization that it was taking me more research time than might be consumed by someone who has them neatly arranged in a bookshelf in their office. Everything you related, plus some other details, I had already found, but I had not sent mail to William describing POSIX.2, XPG2 and XPG3. It did not occur to me that William might be getting impatient, submitting to Mantis before "we" both understood where date_fmt originated and whether it was necessary to change any standard. My fault, not his. The only reference to date_fmt I found in any standard related document I possess is in the Tenth Unicode Conference Proceedings, which had a non-normative example of a Solaris header file ((c) 1996) that describes the LC_TIME options. It was obviously an extension that was added by Sun Microsystems. My present conclusion is that this Solaris extension has no place in the POSIX standard, but I am continuing the research with William to find out where he "discovered" date_fmt (such as, perhaps, Linux). It might also be in the unpublished SVID-4 (which I think I have somewhere). I will also be coaching William about the undocumented, arcane procedures that we operate under in the Austin Group forum. We do not make it easy for a new member to learn how we do our business. Cheers, Larry On 5/26/2020 4:19 AM, Geoff Clare wrote: == https://www.austingroupbugs.net/view.php?id=1345 == Summary:date(1) default format Description: PREFACE For simplicity I will state XPG3 positions as fact, although I do not actually have access to the XPG3 standard. The XPG3 references are not imperative to addressing this issue, they merely give plausible explanation for the current situation. Anyone with access to the XPG3 standard is welcome to confirm or deny. Finally, I'm new here and will likely do something wrong; I plead for patience and guidance, please. If you weren't sure whether your assumptions about what was in XPG3 were true, it would have made sense to ask on the mailing list for confirmation, before committing them as assumed "fact" to a Mantis bug. I'm afraid that your assumptions were wrong - details below. Terms: default format: when calling date(1) without arguments. There are two closely related issues for the date(1) default format: a) the default format is ambiguous: Stated: shall be the locale specific 'date and time'. Not Stated: what locale element represents it. Line 85674: By default, the current date and time shall be written. Line 85805: ... the [default format] output in the POSIX locale ... Lines 85864-85892 EXAMPLES [also illustrate locale specific default formats] b) the STDOUT POSIX locale format string is unreachable Line 85807 date "+%a %b %e %H:%M:%S %Z %Y" PLAUSIBLE EXPLANATION ___ XPG3 XPG3 specified the date(1) default output format as %C [uppercase 'C']. It was bound to the date_fmt locale element: date(1) %C locale’s date and time representation as produced by date(1) STDOUT When no formatting operand is specified, the output in the POSIX locale shall be equivalent to specifying: date "+%a %b %e %H:%M:%S %Z %Y" POSIX Locale # date and time representation as produced by date(1) (%C) # "%a %b %e %H:%M:%S %Z %Y" date_fmt " ... NOTE: the format in date(1) STDOUT was reachable via LC_TIME date_fmt; %C None of the above is true. There was no %C format in XPG3's date. There was no STDOUT section in XPG3 utility man pages. The output format for date with no argument was not specified in XPG3, even for the POSIX locale. There were no "locale keywords" at all in XPG3. The closest thing it had to that was nl_langinfo() - which had D_T_FMT, D_FMT and T_FMT. . . . deleted . . .
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
Geoff Clare wrote: > I believe that leaving the default format unspecified, except for the > POSIX locale, was intentional. The same approach was taken for many > other utilities whose behaviour is affected by locale settings. I guess that there are too many languages, that differ from the european centric date format, that you cannot define a specified format that does not at the same time makes many people on the world unhappy. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
> == > https://www.austingroupbugs.net/view.php?id=1345 > == > Summary:date(1) default format > Description: > PREFACE > For simplicity I will state XPG3 positions as fact, although I do not > actually > have access to the XPG3 standard. The XPG3 references are not imperative > to > addressing this issue, they merely give plausible explanation for the > current > situation. Anyone with access to the XPG3 standard is welcome to confirm > or > deny. Finally, I'm new here and will likely do something wrong; I plead > for > patience and guidance, please. If you weren't sure whether your assumptions about what was in XPG3 were true, it would have made sense to ask on the mailing list for confirmation, before committing them as assumed "fact" to a Mantis bug. I'm afraid that your assumptions were wrong - details below. > Terms: > default format: when calling date(1) without arguments. > > There are two closely related issues for the date(1) default format: > > a) the default format is ambiguous: >Stated: shall be the locale specific 'date and time'. >Not Stated: what locale element represents it. > >Line 85674: > By default, the current date and time shall be written. >Line 85805: > ... the [default format] output in the POSIX locale ... >Lines 85864-85892 > EXAMPLES [also illustrate locale specific default formats] > > b) the STDOUT POSIX locale format string is unreachable >Line 85807 date "+%a %b %e %H:%M:%S %Z %Y" > > PLAUSIBLE EXPLANATION > ___ > XPG3 > > XPG3 specified the date(1) default output format as %C [uppercase 'C']. > It was bound to the date_fmt locale element: > > date(1) > %C locale’s date and time representation as produced by date(1) > > STDOUT > When no formatting operand is specified, the output in the POSIX locale > shall > be equivalent to specifying: date "+%a %b %e %H:%M:%S %Z %Y" > > POSIX Locale > # date and time representation as produced by date(1) (%C) > # "%a %b %e %H:%M:%S %Z %Y" > date_fmt " ... > > NOTE: the format in date(1) STDOUT was reachable via LC_TIME date_fmt; %C None of the above is true. There was no %C format in XPG3's date. There was no STDOUT section in XPG3 utility man pages. The output format for date with no argument was not specified in XPG3, even for the POSIX locale. There were no "locale keywords" at all in XPG3. The closest thing it had to that was nl_langinfo() - which had D_T_FMT, D_FMT and T_FMT. > ___ > XPG4 > > In XPG4 %C was redefined to Century number and date_fmt was dropped from > the > POSIX locale. However, the change seemed to overlook establishing a new > date(1) > default format specifier and did not fix the dangling reference to the > deleted > date_fmt in the date(1) STDOUT section. %C was new in XPG4 (via POSIX.2-1992). There was never a standard date_fmt. The STDOUT section (new in XPG4) specified the default output format for the POSIX locale as "%a %b %e %H:%M:%S %Z %Y". (This requirement also came from POSIX.2-1992.) > ___ > IMPACT > The required default date(1) POSIX locale format being unavailable has lead > to > implementation creativity. Glibc and coreutils have partially reimplemented > the > XPG3 date_fmt as the default date(1) format without binding it to a format > specifier. There have been several posts to the glibc mailing list asking > what > are the expected values for d_t_fmt and date_fmt. Nobody knows. I think > the > reason date_fmt was reintroduced is to resolve the unreachable format > string > the standard requires in the date(1) STDOUT section. I believe that leaving the default format unspecified, except for the POSIX locale, was intentional. The same approach was taken for many other utilities whose behaviour is affected by locale settings. > ___ > SOLUTION > > a) The de facto date(1) default format must be %c (LC_TIME d_t_fmt). >It is the only locale keyword that satisfies the required 'date and > time'. Absolutely not. The default output for the POSIX locale is not the same as %c and never has been. There is zero chance of this being changed. Even requiring it to be the same as %c for other locales would, I think, not achieve consensus as it would force many implementations to change for no good reason. >The several date(1) EXAMPLES seem to support this position. None of the examples show what the output from "date +%c" would be, so I don't see how they support making the default the same as %c. > b) date(1) STDOUT should not be restating the POSIX locale. It should >simply state %c, and let the POSIX locale speak for itself. > >That leaves the conflict between the current format string listed in > STDOUT >and the value for the POSIX
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
On Mon, 25 May 2020, Larry Dwyer wrote: Hi Willie, The quotes you attribute to XPG3 are actually from XPG4. Do you have access to XPG3? If yes, could you send me the items that I requested from it? Yes, the string you quote below: 3012 date "+%a %b %e %H:%M:%S %Z %Y" Is in XPG4 and it's still in the current standards. However, I think it's origin was XPG3, and when XPG4 dropped date_fmt, which was the locale keyword which made the default format string reachable, they overlooked fixing this dangling (unreachable through locale LC_TIME) default format. That is the one of the points of this defect report. It was my fault that I did not make this clear to you when I sent the quotes from my library. It wasn't your fault at all. You made clear that you sent me XPG4 information. I just do not think that is the origin of the format. I could be wrong, but that is how it looks to me. I wish that I could access the XPG3 standard somewhere. In another part of XPG4, it is stated that the XPG4 is aligned with the (newly) published POSIX 1003.2, 1992. The P1003.2 states: IEEE Std 1003.2-1992 2885 4.15 date - Write the date and time 2886 4.15.1 Synopsis 2887 date [-u] [+format] 3009 4.15.6.1 Standard Output 3010 When no formatting operand is specified, the output in the POSIX Locale shall be 3011 equivalent to specifying 3012 date "+%a %b %e %H:%M:%S %Z %Y" Does that standard define the POSIX locale? What LC_TIME keyword is the above format bound to? Thank you for helping Larry, Willie I am sorry I was not clear that the quotes I sent to you were from XPG4 (as opposed to XPG3). Cheers, Larry On 5/24/2020 3:48 PM, Austin Group Bug Tracker wrote: The following issue has been SUBMITTED. == https://www.austingroupbugs.net/view.php?id=1345 == Reported By:j_willie Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1345 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: J William Piggott Organization: User Reference: Section:date Page Number:163, 2634-2638 Line Number:5224-5228, 85673-85823 Interp Status: --- Final Accepted Text: == Date Submitted: 2020-05-24 22:48 UTC Last Modified: 2020-05-24 22:48 UTC == Summary:date(1) default format Description: PREFACE For simplicity I will state XPG3 positions as fact, although I do not actually have access to the XPG3 standard. The XPG3 references are not imperative to addressing this issue, they merely give plausible explanation for the current situation. Anyone with access to the XPG3 standard is welcome to confirm or deny. Finally, I'm new here and will likely do something wrong; I plead for patience and guidance, please. Terms: default format: when calling date(1) without arguments. There are two closely related issues for the date(1) default format: a) the default format is ambiguous: Stated: shall be the locale specific 'date and time'. Not Stated: what locale element represents it. Line 85674: By default, the current date and time shall be written. Line 85805: ... the [default format] output in the POSIX locale ... Lines 85864-85892 EXAMPLES [also illustrate locale specific default formats] b) the STDOUT POSIX locale format string is unreachable Line 85807 date "+%a %b %e %H:%M:%S %Z %Y" PLAUSIBLE EXPLANATION ___ XPG3 XPG3 specified the date(1) default output format as %C [uppercase 'C']. It was bound to the date_fmt locale element: date(1) %C locale’s date and time representation as produced by date(1) STDOUT When no formatting operand is specified, the output in the POSIX locale shall be equivalent to specifying: date "+%a %b %e %H:%M:%S %Z %Y" POSIX Locale # date and time representation as produced by date(1) (%C) # "%a %b %e %H:%M:%S %Z %Y" date_fmt " ... NOTE: the format in date(1) STDOUT was reachable via LC_TIME date_fmt; %C ___ XPG4 In XPG4 %C was redefined to Century number and date_fmt was dropped from the POSIX locale. However, the change seemed to overlook establishing a new date(1) default format specifier and did not fix the dangling reference to the deleted date_fmt in the date(1) STDOUT section. ___ IMPACT The required default date(1) POSIX locale format being unavailable has lead to implementation creativity. Glibc and
Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format
Hi Willie, The quotes you attribute to XPG3 are actually from XPG4. It was my fault that I did not make this clear to you when I sent the quotes from my library. In another part of XPG4, it is stated that the XPG4 is aligned with the (newly) published POSIX 1003.2, 1992. The P1003.2 states: IEEE Std 1003.2-1992 2885 4.15 date - Write the date and time 2886 4.15.1 Synopsis 2887 date [-u] [+format] 3009 4.15.6.1 Standard Output 3010 When no formatting operand is specified, the output in the POSIX Locale shall be 3011 equivalent to specifying 3012 date "+%a %b %e %H:%M:%S %Z %Y" I am sorry I was not clear that the quotes I sent to you were from XPG4 (as opposed to XPG3). Cheers, Larry On 5/24/2020 3:48 PM, Austin Group Bug Tracker wrote: The following issue has been SUBMITTED. == https://www.austingroupbugs.net/view.php?id=1345 == Reported By:j_willie Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1345 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: J William Piggott Organization: User Reference: Section:date Page Number:163, 2634-2638 Line Number:5224-5228, 85673-85823 Interp Status: --- Final Accepted Text: == Date Submitted: 2020-05-24 22:48 UTC Last Modified: 2020-05-24 22:48 UTC == Summary:date(1) default format Description: PREFACE For simplicity I will state XPG3 positions as fact, although I do not actually have access to the XPG3 standard. The XPG3 references are not imperative to addressing this issue, they merely give plausible explanation for the current situation. Anyone with access to the XPG3 standard is welcome to confirm or deny. Finally, I'm new here and will likely do something wrong; I plead for patience and guidance, please. Terms: default format: when calling date(1) without arguments. There are two closely related issues for the date(1) default format: a) the default format is ambiguous: Stated: shall be the locale specific 'date and time'. Not Stated: what locale element represents it. Line 85674: By default, the current date and time shall be written. Line 85805: ... the [default format] output in the POSIX locale ... Lines 85864-85892 EXAMPLES [also illustrate locale specific default formats] b) the STDOUT POSIX locale format string is unreachable Line 85807 date "+%a %b %e %H:%M:%S %Z %Y" PLAUSIBLE EXPLANATION ___ XPG3 XPG3 specified the date(1) default output format as %C [uppercase 'C']. It was bound to the date_fmt locale element: date(1) %C locale’s date and time representation as produced by date(1) STDOUT When no formatting operand is specified, the output in the POSIX locale shall be equivalent to specifying: date "+%a %b %e %H:%M:%S %Z %Y" POSIX Locale # date and time representation as produced by date(1) (%C) # "%a %b %e %H:%M:%S %Z %Y" date_fmt " ... NOTE: the format in date(1) STDOUT was reachable via LC_TIME date_fmt; %C ___ XPG4 In XPG4 %C was redefined to Century number and date_fmt was dropped from the POSIX locale. However, the change seemed to overlook establishing a new date(1) default format specifier and did not fix the dangling reference to the deleted date_fmt in the date(1) STDOUT section. ___ IMPACT The required default date(1) POSIX locale format being unavailable has lead to implementation creativity. Glibc and coreutils have partially reimplemented the XPG3 date_fmt as the default date(1) format without binding it to a format specifier. There have been several posts to the glibc mailing list asking what are the expected values for d_t_fmt and date_fmt. Nobody knows. I think the reason date_fmt was reintroduced is to resolve the unreachable format string the standard requires in the date(1) STDOUT section. ___ SOLUTION a) The de facto date(1) default format must be %c (LC_TIME d_t_fmt). It is the only locale keyword that satisfies the required 'date and time'. The several date(1) EXAMPLES seem to support this position. b) date(1) STDOUT should not be restating the POSIX locale. It should simply state %c, and let the POSIX locale speak for itself. That leaves the conflict between the current format string listed in STDOUT and the value for the POSIX locale
