| Message ID | 20181230235437.20485-1-aurelien@aurel32.net |
|---|---|
| State | New |
| Headers | show |
| Series | en_US: define date_fmt (bug 24046) | expand |
31.12.2018 00:54 Aurelien Jarno <aurelien@aurel32.net> wrote: > > > The en_US locale use a 12h am/pm format in both d_fmt and d_t_fmt, which > is correct, but does not define date_fmt. This cause the default value > to be used, which is in 24h format. I thought it was deliberate. But indeed, AFAIK 24h clock is not commonly understood in the USA. Are you a local citizen and can you confirm? > [...] > Changelog > [BZ #24046] > * localedata/locales/en_US (date_fmt): Define. I'm not sure that your comment is wrong but when I add a new field I'm also trying to quote its value. I think it is weird that we quote a value when we change it but not when we define it for the first time. > --- > ChangeLog | 5 +++++ > localedata/locales/en_US | 3 +++ > 2 files changed, 8 insertions(+) > > diff --git a/ChangeLog b/ChangeLog > index a2170167c7..8f90d99290 100644 > --- a/ChangeLog > +++ b/ChangeLog Please remove changes to ChangeLog itself when posting here. It makes your patchwork impossible to apply. However, it's not a big problem in case of such a trivial patch. > diff --git a/localedata/locales/en_US b/localedata/locales/en_US > index 5e2b365659..2c808bbfb6 100644 > --- a/localedata/locales/en_US > +++ b/localedata/locales/en_US > @@ -117,6 +117,9 @@ t_fmt "%r" > % Appropriate AM/PM time representation (%r) > t_fmt_ampm "%I:%M:%S %p" > % > +% Appropriate date representation (date(1)) I know that many locales have this comment already but can we invent something different to avoid nested parentheses here? Otherwise looks OK. This is the last day before freeze so please wait several hours and feel free to push to master if nobody complains and if you are sure it is correct. I'm out of my PC, unable to test, posting from my phone. Regards, Rafal
On 2018-12-31 02:14, Rafal Luzynski wrote: > 31.12.2018 00:54 Aurelien Jarno <aurelien@aurel32.net> wrote: > > > > > > The en_US locale use a 12h am/pm format in both d_fmt and d_t_fmt, which > > is correct, but does not define date_fmt. This cause the default value > > to be used, which is in 24h format. > > I thought it was deliberate. But indeed, > AFAIK 24h clock is not commonly understood > in the USA. Are you a local citizen and > can you confirm? I am not a local citizen. That said it has been reported in Debian bug #877900, and confirmed by one local citizen I know. > > [...] > > Changelog > > [BZ #24046] > > * localedata/locales/en_US (date_fmt): Define. > > I'm not sure that your comment is wrong but > when I add a new field I'm also trying to > quote its value. I think it is weird that > we quote a value when we change it but not > when we define it for the first time. I'll change that. > > --- > > ChangeLog | 5 +++++ > > localedata/locales/en_US | 3 +++ > > 2 files changed, 8 insertions(+) > > > > diff --git a/ChangeLog b/ChangeLog > > index a2170167c7..8f90d99290 100644 > > --- a/ChangeLog > > +++ b/ChangeLog > > Please remove changes to ChangeLog itself > when posting here. It makes your patchwork > impossible to apply. However, it's not a big > problem in case of such a trivial patch. I have git-merge-changelog and it takes care of merging the ChangeLog, you just have to adjust the date if needed. However If people prefer I stop changing the ChangeLog in my patches. > > diff --git a/localedata/locales/en_US b/localedata/locales/en_US > > index 5e2b365659..2c808bbfb6 100644 > > --- a/localedata/locales/en_US > > +++ b/localedata/locales/en_US > > @@ -117,6 +117,9 @@ t_fmt "%r" > > % Appropriate AM/PM time representation (%r) > > t_fmt_ampm "%I:%M:%S %p" > > % > > +% Appropriate date representation (date(1)) > > I know that many locales have this comment > already but can we invent something different > to avoid nested parentheses here? Something like "Appropriate date representation for the date utility"? Regards, Aurelien
* Aurelien Jarno: > The en_US locale use a 12h am/pm format in both d_fmt and d_t_fmt, which > is correct, but does not define date_fmt. This cause the default value > to be used, which is in 24h format. Perhaps this format was chosen for alignment with asctime? Is there any system which uses 12h format with the date command? I wonder whether our users expect such a change.
On 2018-12-31 11:53, Florian Weimer wrote: > * Aurelien Jarno: > > > The en_US locale use a 12h am/pm format in both d_fmt and d_t_fmt, which > > is correct, but does not define date_fmt. This cause the default value > > to be used, which is in 24h format. > > Perhaps this format was chosen for alignment with asctime? I don't think this has been a deliberated choice. Support for date_fmt (which is a GNU extension), has been added back in 2000 in commit d8337213c8. At that time all locales got date_fmt set to the default setting, and later locales got this value updated through the years. This has never been done for the US locale. Then in commit 2e7a461328 all locales with the default value got this field removed. > Is there any system which uses 12h format with the date command? Yes, the following locale use a 12h format with the date command: aa_DJ aa_ER aa_ET am_ET az_IR byn_ER el_CY el_GR fa_IR gez_ER gez_ET ku_TR lzh_TW om_ET om_KE sid_ET so_DJ so_ET so_KE so_SO ti_ER ti_ET tig_ER uz_UZ wal_ET > I wonder whether our users expect such a change. At least a few users, but I agree it's difficult to know for the majority of users. Regards, Aurelien
* Aurelien Jarno: >> Is there any system which uses 12h format with the date command? > > Yes, the following locale use a 12h format with the date command: > aa_DJ aa_ER aa_ET am_ET az_IR byn_ER el_CY el_GR fa_IR gez_ER gez_ET > ku_TR lzh_TW om_ET om_KE sid_ET so_DJ so_ET so_KE so_SO ti_ER ti_ET > tig_ER uz_UZ wal_ET Sorry, I meant other UNIX-like systems that use 12h format by defaul, without any specific locale selection.
On 2018-12-31 12:11, Florian Weimer wrote: > * Aurelien Jarno: > > >> Is there any system which uses 12h format with the date command? > > > > Yes, the following locale use a 12h format with the date command: > > aa_DJ aa_ER aa_ET am_ET az_IR byn_ER el_CY el_GR fa_IR gez_ER gez_ET > > ku_TR lzh_TW om_ET om_KE sid_ET so_DJ so_ET so_KE so_SO ti_ER ti_ET > > tig_ER uz_UZ wal_ET > > Sorry, I meant other UNIX-like systems that use 12h format by defaul, > without any specific locale selection. I don't think that's the case. UNIX-like systems are supposed to follow POSIX, and "%X" and "%c" are defined in 24h format without locale selection.
31.12.2018 10:30 Aurelien Jarno <aurelien@aurel32.net> wrote: > [...] > I have git-merge-changelog and it takes care of merging the ChangeLog, > you just have to adjust the date if needed. However If people prefer I > stop changing the ChangeLog in my patches. AFAIK yes, people prefer this. This is not my personal requirement, I was asked not to post changes to ChangeLog before. > > > > diff --git a/localedata/locales/en_US b/localedata/locales/en_US > > > index 5e2b365659..2c808bbfb6 100644 > > > --- a/localedata/locales/en_US > > > +++ b/localedata/locales/en_US > > > @@ -117,6 +117,9 @@ t_fmt "%r" > > > % Appropriate AM/PM time representation (%r) > > > t_fmt_ampm "%I:%M:%S %p" > > > % > > > +% Appropriate date representation (date(1)) > > > > I know that many locales have this comment > > already but can we invent something different > > to avoid nested parentheses here? > > Something like "Appropriate date representation for the date utility"? I used "Appropriate date and time representation for date(1)" but I don't claim that my version is perfect. However, please note that I used "date and time" and this sounds for me more accurate than just "date". Otherwise, thank you for your effort. Regards, Rafal
31.12.2018 14:59 Aurelien Jarno <aurelien@aurel32.net> wrote: > > On 2018-12-31 12:11, Florian Weimer wrote: > > * Aurelien Jarno: > > > > >> Is there any system which uses 12h format with the date command? > > > > > > Yes, the following locale use a 12h format with the date command: > > > aa_DJ aa_ER aa_ET am_ET az_IR byn_ER el_CY el_GR fa_IR gez_ER gez_ET > > > ku_TR lzh_TW om_ET om_KE sid_ET so_DJ so_ET so_KE so_SO ti_ER ti_ET > > > tig_ER uz_UZ wal_ET > > > > Sorry, I meant other UNIX-like systems that use 12h format by defaul, > > without any specific locale selection. > > I don't think that's the case. UNIX-like systems are supposed to follow > POSIX, and "%X" and "%c" are defined in 24h format without locale > selection. This patch is for en_US only and I don't think that POSIX says it should be 24h clock in every locale. en_US locale is not default, it is used only when explicitly requested. Although I am aware that usually it is usually preset. But it does not overwrite POSIX. I think that it should be 12h in en_US locale and in every locale where people request it. It's not hurting anyone using a different locale (modulo those who use “copy "en_US"” but I assume they do it deliberately.) Regards, Rafal
31.12.2018 12:07 Aurelien Jarno <aurelien@aurel32.net> wrote: > > [...] > I don't think this has been a deliberated choice. Support for date_fmt > (which is a GNU extension), has been added back in 2000 in commit > d8337213c8. At that time all locales got date_fmt set to the default > setting, and later locales got this value updated through the years. > This has never been done for the US locale. Then in commit 2e7a461328 > all locales with the default value got this field removed. Thank you for this research. There are many locales which don't have date_fmt defined which means they use the default value from C locale: "%a %b %e %H:%M:%S %Z %Y". This is bad for many of them because this assumes the date order is MDY which is not the most popular order around the world. I did not yet have time to file a bug report and/or fix it, anybody feel free to do it. > [...] > > I wonder whether our users expect such a change. > > At least a few users, but I agree it's difficult to know for the > majority of users. I think we had sufficient confirmations here. Regards, Rafal
On 2018-12-31 19:16, Rafal Luzynski wrote: > 31.12.2018 12:07 Aurelien Jarno <aurelien@aurel32.net> wrote: > > > > [...] > > I don't think this has been a deliberated choice. Support for date_fmt > > (which is a GNU extension), has been added back in 2000 in commit > > d8337213c8. At that time all locales got date_fmt set to the default > > setting, and later locales got this value updated through the years. > > This has never been done for the US locale. Then in commit 2e7a461328 > > all locales with the default value got this field removed. > > Thank you for this research. There are many locales which don't have > date_fmt defined which means they use the default value from C locale: > "%a %b %e %H:%M:%S %Z %Y". This is bad for many of them because this > assumes the date order is MDY which is not the most popular order By looking at the difference between d_t_fmt and date_fmt in the locales having both, it seems to me that the later has been added to display the full date and time, including the timezone. Indeed for countries that only span a single timezone, it is usually not displayed. I have added Jim Meyering in Cc: who have done commit 5ca6863e97 on the coreutils side, so that the can confirm about that. If he stills remember of course, as the commit has been done more than 18 years ago... > around the world. I did not yet have time to file a bug report and/or > fix it, anybody feel free to do it. I have just opened BZ 24054 about that. > > [...] > > > I wonder whether our users expect such a change. > > > > At least a few users, but I agree it's difficult to know for the > > majority of users. > > I think we had sufficient confirmations here. Given we are now in freeze period and given the patch has been posted only recently in a period with many people away from their computer, I think it's better to wait a bit to give the chance for other people to comment. After all it has been like that for more than 18 years, so we can wait a few weeks more. I'll repost this patch once glibc 2.29 has been released. Regards, Aurelien
Aurelien Jarno wrote: > I have added Jim Meyering in Cc: who have done commit 5ca6863e97 on the > coreutils side, so that the can confirm about that. If he stills > remember of course, as the commit has been done more than 18 years > ago... That's so long ago that it's not in the GNU mailing list archives. However, as I vaguely recall, Jim and I worked together on this, and the idea was that the output of plain 'date' should be locale-dependent, that there was a mechanism to do that in Solaris even though it was not in POSIX, and that we should use that mechanism. I no longer have access to Solaris 8 (the circa 2000 version), but on Solaris 10 in an en_US.ISO8859-1 locale if I run 'TZ=UTC0 date' the output is: Wednesday, January 2, 2019 08:19:11 PM UTC so it is indeed using 12-hour time with AM/PM, and with a timezone indication.
2.01.2019 18:41 Aurelien Jarno <aurelien@aurel32.net> wrote: > > On 2018-12-31 19:16, Rafal Luzynski wrote: > > 31.12.2018 12:07 Aurelien Jarno <aurelien@aurel32.net> wrote: > > > > [...] > By looking at the difference between d_t_fmt and date_fmt in the locales > having both, it seems to me that the later has been added to display the > full date and time, including the timezone. I have the same impression looking at the C locale. > Indeed for countries that > only span a single timezone, it is usually not displayed. I didn't think about it as a matter of whether a country spans one or multiple time zones. I think that if you are asking about the current time of your desktop computer then it is in the same time zone as you no matter how large is your country. OTOH, if you are asking about the current time of a remote computer it is not helpful that your country has only one time zone because the computer may be abroad. But my reasoning may be wrong, feel free to disagree. > [...] > > around the world. I did not yet have time to file a bug report and/or > > fix it, anybody feel free to do it. > > I have just opened BZ 24054 about that. Thank you. > [...] > Given we are now in freeze period and given the patch has been posted > only recently in a period with many people away from their computer, I > think it's better to wait a bit to give the chance for other people to > comment. After all it has been like that for more than 18 years, so we > can wait a few weeks more. I'll repost this patch once glibc 2.29 has > been released. Fair enough. Regards, Rafal
31.12.2018 00:54 Aurelien Jarno <aurelien@aurel32.net> wrote: > --- a/localedata/locales/en_US > +++ b/localedata/locales/en_US > @@ -117,6 +117,9 @@ t_fmt "%r" > % Appropriate AM/PM time representation (%r) > t_fmt_ampm "%I:%M:%S %p" > % > +% Appropriate date representation (date(1)) > +date_fmt "%a %d %b %Y %I:%M:%S %p %Z" I thought about it only now. For the consistency with d_t_fmt, could we use this? date_fmt "%a %d %b %Y %r %Z" The output of "%r" is defined by t_fmt_ampm which is "%I:%M:%S %p" in en_US. Also, please note that here we are switching from "%a %b %e" (month-day order) to "%a %d %b" (day-month order). I hope this is not confusing for the US citizens, especially since d_t_fmt already has day-month order and since "%b" cannot be mistaken for the day number. en_GB has the day-month order in both date_fmt and d_t_fmt. Regards, Rafal
On 2019-01-03 00:23, Rafal Luzynski wrote: > 2.01.2019 18:41 Aurelien Jarno <aurelien@aurel32.net> wrote: > > > > On 2018-12-31 19:16, Rafal Luzynski wrote: > > > 31.12.2018 12:07 Aurelien Jarno <aurelien@aurel32.net> wrote: > > > > > > [...] > > By looking at the difference between d_t_fmt and date_fmt in the locales > > having both, it seems to me that the later has been added to display the > > full date and time, including the timezone. > > I have the same impression looking at the C locale. > > > Indeed for countries that > > only span a single timezone, it is usually not displayed. > > I didn't think about it as a matter of whether a country spans one or > multiple time zones. I think that if you are asking about the current > time of your desktop computer then it is in the same time zone as you > no matter how large is your country. OTOH, if you are asking about the > current time of a remote computer it is not helpful that your country > has only one time zone because the computer may be abroad. But my > reasoning may be wrong, feel free to disagree. > My point was that country spanning multiple time zones usually (or should?) already have the time zone indicated in d_t_fmt, so d_t_fmt and date_fmt should be the same. At least that was my impression looking only at a few locales. However after grepping the existing locales, it is not that clear anymore. The presence of %z or %Z in d_t_fmt seems mostly random. And often different in t_fmt... Regards, Aurelien
* Paul Eggert: > […] I no longer have access to Solaris 8 (the circa 2000 version), but > on Solaris 10 in an en_US.ISO8859-1 locale if I run 'TZ=UTC0 date' the > output is: > > Wednesday, January 2, 2019 08:19:11 PM UTC > > so it is indeed using 12-hour time with AM/PM, and with a timezone > indication. Thanks. This suggests that changing the locale should not cause too many problems. Florian
3.01.2019 00:47 Aurelien Jarno <aurelien@aurel32.net> wrote: > [...] > My point was that country spanning multiple time zones usually (or > should?) already have the time zone indicated in d_t_fmt, so d_t_fmt and > date_fmt should be the same. At least that was my impression looking > only at a few locales. > > However after grepping the existing locales, it is not that clear > anymore. The presence of %z or %Z in d_t_fmt seems mostly random. And > often different in t_fmt... I'm not aware of any rule saying whether d_t_fmt should include a time zone or not. Additionally, date_fmt is a GNU extension. But I perceive the built in C locale as a model implementation. Other locales may be pretty sloppy. In C locale the only difference between d_t_fmt and date_fmt is that date_fmt contains the time zone while d_t_fmt does not. So, have we agreed that we can switch date_fmt in en_US to 12 hour format? Can we do it now despite the freeze period? What do you think about my suggestion to use "%r" instead of "%I:%M:%S %p"? Regards, Rafal
On 2019-01-05 01:19, Rafal Luzynski wrote: > 3.01.2019 00:47 Aurelien Jarno <aurelien@aurel32.net> wrote: > > [...] > > My point was that country spanning multiple time zones usually (or > > should?) already have the time zone indicated in d_t_fmt, so d_t_fmt and > > date_fmt should be the same. At least that was my impression looking > > only at a few locales. > > > > However after grepping the existing locales, it is not that clear > > anymore. The presence of %z or %Z in d_t_fmt seems mostly random. And > > often different in t_fmt... > > I'm not aware of any rule saying whether d_t_fmt should include a time > zone or not. Additionally, date_fmt is a GNU extension. But I perceive > the built in C locale as a model implementation. Other locales may be > pretty sloppy. In C locale the only difference between d_t_fmt and > date_fmt is that date_fmt contains the time zone while d_t_fmt does not. Yes, I agree that there is no rule, and that probably explains while there are so many variants. Usually one creates a locale using another one as an example. There is at least the case of zh_HK for which t_fmt contains the time zone, but not d_t_fmt. That looks strange to me. > So, have we agreed that we can switch date_fmt in en_US to 12 hour > format? Personally I am convinced it's the right thing to do. > Can we do it now despite the freeze period? I think it's more a question for Siddhesh. > What do you > think about my suggestion to use "%r" instead of "%I:%M:%S %p"? That's more a technical question. I used this form, because the C locale expands the conversion specifications. But if we can technically use "%r", it's fine for me, I can update the patch. Can we even use "%c" directly? Regards, Aurelien
5.10.2019 01:39 Aurelien Jarno <aurelien@aurel32.net> wrote: > > On 2019-01-05 01:19, Rafal Luzynski wrote: > [...] > Yes, I agree that there is no rule, and that probably explains while > there are so many variants. Usually one creates a locale using another > one as an example. I believe this is the case. > There is at least the case of zh_HK for which t_fmt contains the > time zone, but not d_t_fmt. That looks strange to me. I was reworking this recently but I have not changed (added/removed) anything with the time zones. It has been for long time as it is now. > > So, have we agreed that we can switch date_fmt in en_US to 12 hour > > format? > > Personally I am convinced it's the right thing to do. > > > Can we do it now despite the freeze period? > > I think it's more a question for Siddhesh. I'm adding CC: Siddhesh, what do you think? The patch is not yet ready but the general idea is to use 12h time format in en_US instead of 24h. We have agreed that this is a good idea for US users, we are only discussing how to implement the format and whether to do it now or postpone until 2.30. > > What do you > > think about my suggestion to use "%r" instead of "%I:%M:%S %p"? > > That's more a technical question. I used this form, because the C locale > expands the conversion specifications. But if we can technically use > "%r", it's fine for me, I can update the patch. Can we even use "%c" > directly? I think I have not seen "%c" in any locale but I'm not aware of any technical limitation. Does it make any difference, like a performance drop? Probably yes and probably negligible. Please test thoroughly and please post here before committing so other people will be able to test as well. Thank you and regards, Rafal
On 2019-01-05 15:24, Rafal Luzynski wrote: > 5.10.2019 01:39 Aurelien Jarno <aurelien@aurel32.net> wrote: > > > > On 2019-01-05 01:19, Rafal Luzynski wrote: > [...] > > > What do you > > > think about my suggestion to use "%r" instead of "%I:%M:%S %p"? > > > > That's more a technical question. I used this form, because the C locale > > expands the conversion specifications. But if we can technically use > > "%r", it's fine for me, I can update the patch. Can we even use "%c" > > directly? > > I think I have not seen "%c" in any locale but I'm not aware of any > technical limitation. Does it make any difference, like a performance > drop? Probably yes and probably negligible. Please test thoroughly I have tried using "%c" and it works fine on my system. That said, given no other locales use this, I am a bit reluctant to do that change now. > and please post here before committing so other people will be able > to test as well. I have just posted an updated version of the patch, which sticks to "%a %d %b %Y %r %Z" and has and update comment. I have tested it here and I have also checked it doesn't cause any regression in the testsuite, as the en_US locale is used in a few tests. Regards, Aurelien
On 05/01/19 7:54 PM, Rafal Luzynski wrote: > I'm adding CC: Siddhesh, what do you think? The patch is not yet > ready but the general idea is to use 12h time format in en_US > instead of 24h. We have agreed that this is a good idea for US > users, we are only discussing how to implement the format and whether > to do it now or postpone until 2.30. OK for 2.29. Siddhesh
6.01.2019 18:19 Aurelien Jarno <aurelien@aurel32.net> wrote: > [...] > I have tried using "%c" and it works fine on my system. That said, given > no other locales use this, I am a bit reluctant to do that change now. I totally agree with that. Regards, Rafal
diff --git a/ChangeLog b/ChangeLog index a2170167c7..8f90d99290 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2018-12-31 Aurelien Jarno <aurelien@aurel32.net> + + [BZ #24046] + * localedata/locales/en_US (date_fmt): Define. + 2018-12-28 Justus Winter <4winter@informatik.uni-hamburg.de> * hurd/lookup-retry: Include <unistd.h>. diff --git a/localedata/locales/en_US b/localedata/locales/en_US index 5e2b365659..2c808bbfb6 100644 --- a/localedata/locales/en_US +++ b/localedata/locales/en_US @@ -117,6 +117,9 @@ t_fmt "%r" % Appropriate AM/PM time representation (%r) t_fmt_ampm "%I:%M:%S %p" % +% Appropriate date representation (date(1)) +date_fmt "%a %d %b %Y %I:%M:%S %p %Z" +% % Strings for AM/PM % am_pm "AM";"PM"