Bug#785118: coreutils: date : format %p %P do not work properly
On Tue, May 12, 2015 at 07:55:40PM +0300, Marko Myllynen wrote: Hi, [CC'ing Keld with whom this issue was discussed some years ago] On 2015-05-12 18:49, Pádraig Brady wrote: On 12/05/15 16:40, Pádraig Brady wrote: On 12/05/15 14:51, Michael Stone wrote: On Tue, May 12, 2015 at 03:36:17PM +0200, op...@mumm.ac.be wrote: I'm just upgrading my server from debian 7 (wheezy) to debian 8 (jessie) and several of my scripts are not working anymore. After some tests, it turns out that the problem likely comes from the fact the 'date' function does not work as expected. In wheezy, the command line date /bin/date +%Y%m%d.%p would have returned 20150512.PM In jessie, the same command line returns 20150512. omitting PM. As a consequence of this omission, my scripts are crashing. Have you got any idea why this is happening? I can't reproduce it: /bin/date +%Y%m%d.%p 20150512.AM If I had to guess, I'd say it's a locale issue. What does env LANG=C LC_ALL=C /bin/date +%Y%m%d.%p return? If that works, what does locale return when run by itself? %p is blank in many locales unfortunately. You can see the am_pm vary with these commands: $ LC_ALL=en_IE locale -k LC_TIME $ LC_TIME=C locale -k LC_TIME $ LC_ALL=zh_CN.utf8 date +%p ?? $ LC_ALL=en_US.utf8 date +%p PM $ LC_ALL=en_US date +%p PM locales with blank am_pm should be fixed up to allow one to get an explicit 12 hour format like `date +%I:%m%p` for example. Note some locales (like en_GB for example) default to 24 hour (t_fmt=%T), and also provide an am_pm entry, which is the correct behavior in my opinion. I see that https://sourceware.org/glibc/wiki/Locales states: am_pm and t_fmt_ampm - should be empty if using 24 hour time Marko, that seems incorrect? At least am_pm should be populated to allow users to generate 12 hour time with strftime? I can't find references to the discussion I had with Keld earlier but the rationale for not populating it was along the lines: 1) am_pm should be populated only if AM/PM convention is used to signal applications they should not try to print them when using them is unwanted. Seems that only the locale(5) commit messages, not the page itself, spell this out: http://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/?id=b5d4168adfb426f45108ac2bf7c8b17b126b07a1 http://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/?id=0c2dbad182e40db2ca47128f229ca7dbd83e179f 2) what unwanted means is that in many cases 12 hour time with AM/PM notation is alien thus generating such time representation under those locales would be illogical (e.g. 5.34 ip. in Finnish context is completely unnatural). The same goes for various name_* keywords in LC_NAME, defining them for locales where they are not used would not allow signaling applications that under those locales their usage is unwanted. I think that when running scripts you should ensure that the correct locale is used, and in most cases that would be the C locale. Better set it explicitely. Best regards keld -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785118: coreutils: date : format %p %P do not work properly
On 12/05/15 14:51, Michael Stone wrote: On Tue, May 12, 2015 at 03:36:17PM +0200, op...@mumm.ac.be wrote: I'm just upgrading my server from debian 7 (wheezy) to debian 8 (jessie) and several of my scripts are not working anymore. After some tests, it turns out that the problem likely comes from the fact the 'date' function does not work as expected. In wheezy, the command line date /bin/date +%Y%m%d.%p would have returned 20150512.PM In jessie, the same command line returns 20150512. omitting PM. As a consequence of this omission, my scripts are crashing. Have you got any idea why this is happening? I can't reproduce it: /bin/date +%Y%m%d.%p 20150512.AM If I had to guess, I'd say it's a locale issue. What does env LANG=C LC_ALL=C /bin/date +%Y%m%d.%p return? If that works, what does locale return when run by itself? %p is blank in many locales unfortunately. You can see the am_pm vary with these commands: $ LC_ALL=en_IE locale -k LC_TIME $ LC_TIME=C locale -k LC_TIME $ LC_ALL=zh_CN.utf8 date +%p 下午 $ LC_ALL=en_US.utf8 date +%p PM $ LC_ALL=en_US date +%p PM locales with blank am_pm should be fixed up to allow one to get an explicit 12 hour format like `date +%I:%m%p` for example. Note some locales (like en_GB for example) default to 24 hour (t_fmt=%T), and also provide an am_pm entry, which is the correct behavior in my opinion. cheers, Pádraig -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785118: coreutils: date : format %p %P do not work properly
Hi, [CC'ing Keld with whom this issue was discussed some years ago] On 2015-05-12 18:49, Pádraig Brady wrote: On 12/05/15 16:40, Pádraig Brady wrote: On 12/05/15 14:51, Michael Stone wrote: On Tue, May 12, 2015 at 03:36:17PM +0200, op...@mumm.ac.be wrote: I'm just upgrading my server from debian 7 (wheezy) to debian 8 (jessie) and several of my scripts are not working anymore. After some tests, it turns out that the problem likely comes from the fact the 'date' function does not work as expected. In wheezy, the command line date /bin/date +%Y%m%d.%p would have returned 20150512.PM In jessie, the same command line returns 20150512. omitting PM. As a consequence of this omission, my scripts are crashing. Have you got any idea why this is happening? I can't reproduce it: /bin/date +%Y%m%d.%p 20150512.AM If I had to guess, I'd say it's a locale issue. What does env LANG=C LC_ALL=C /bin/date +%Y%m%d.%p return? If that works, what does locale return when run by itself? %p is blank in many locales unfortunately. You can see the am_pm vary with these commands: $ LC_ALL=en_IE locale -k LC_TIME $ LC_TIME=C locale -k LC_TIME $ LC_ALL=zh_CN.utf8 date +%p 下午 $ LC_ALL=en_US.utf8 date +%p PM $ LC_ALL=en_US date +%p PM locales with blank am_pm should be fixed up to allow one to get an explicit 12 hour format like `date +%I:%m%p` for example. Note some locales (like en_GB for example) default to 24 hour (t_fmt=%T), and also provide an am_pm entry, which is the correct behavior in my opinion. I see that https://sourceware.org/glibc/wiki/Locales states: am_pm and t_fmt_ampm - should be empty if using 24 hour time Marko, that seems incorrect? At least am_pm should be populated to allow users to generate 12 hour time with strftime? I can't find references to the discussion I had with Keld earlier but the rationale for not populating it was along the lines: 1) am_pm should be populated only if AM/PM convention is used to signal applications they should not try to print them when using them is unwanted. Seems that only the locale(5) commit messages, not the page itself, spell this out: http://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/?id=b5d4168adfb426f45108ac2bf7c8b17b126b07a1 http://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/?id=0c2dbad182e40db2ca47128f229ca7dbd83e179f 2) what unwanted means is that in many cases 12 hour time with AM/PM notation is alien thus generating such time representation under those locales would be illogical (e.g. 5.34 ip. in Finnish context is completely unnatural). The same goes for various name_* keywords in LC_NAME, defining them for locales where they are not used would not allow signaling applications that under those locales their usage is unwanted. Thanks, -- Marko Myllynen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785118: coreutils: date : format %p %P do not work properly
On 12/05/15 17:55, Marko Myllynen wrote: Hi, [CC'ing Keld with whom this issue was discussed some years ago] On 2015-05-12 18:49, Pádraig Brady wrote: On 12/05/15 16:40, Pádraig Brady wrote: On 12/05/15 14:51, Michael Stone wrote: On Tue, May 12, 2015 at 03:36:17PM +0200, op...@mumm.ac.be wrote: I'm just upgrading my server from debian 7 (wheezy) to debian 8 (jessie) and several of my scripts are not working anymore. After some tests, it turns out that the problem likely comes from the fact the 'date' function does not work as expected. In wheezy, the command line date /bin/date +%Y%m%d.%p would have returned 20150512.PM In jessie, the same command line returns 20150512. omitting PM. As a consequence of this omission, my scripts are crashing. Have you got any idea why this is happening? I can't reproduce it: /bin/date +%Y%m%d.%p 20150512.AM If I had to guess, I'd say it's a locale issue. What does env LANG=C LC_ALL=C /bin/date +%Y%m%d.%p return? If that works, what does locale return when run by itself? %p is blank in many locales unfortunately. You can see the am_pm vary with these commands: $ LC_ALL=en_IE locale -k LC_TIME $ LC_TIME=C locale -k LC_TIME $ LC_ALL=zh_CN.utf8 date +%p 下午 $ LC_ALL=en_US.utf8 date +%p PM $ LC_ALL=en_US date +%p PM locales with blank am_pm should be fixed up to allow one to get an explicit 12 hour format like `date +%I:%m%p` for example. Note some locales (like en_GB for example) default to 24 hour (t_fmt=%T), and also provide an am_pm entry, which is the correct behavior in my opinion. I see that https://sourceware.org/glibc/wiki/Locales states: am_pm and t_fmt_ampm - should be empty if using 24 hour time Marko, that seems incorrect? At least am_pm should be populated to allow users to generate 12 hour time with strftime? I can't find references to the discussion I had with Keld earlier but the rationale for not populating it was along the lines: 1) am_pm should be populated only if AM/PM convention is used to signal applications they should not try to print them when using them is unwanted. Seems that only the locale(5) commit messages, not the page itself, spell this out: http://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/?id=b5d4168adfb426f45108ac2bf7c8b17b126b07a1 http://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/?id=0c2dbad182e40db2ca47128f229ca7dbd83e179f 2) what unwanted means is that in many cases 12 hour time with AM/PM notation is alien thus generating such time representation under those locales would be illogical (e.g. 5.34 ip. in Finnish context is completely unnatural). The same goes for various name_* keywords in LC_NAME, defining them for locales where they are not used would not allow signaling applications that under those locales their usage is unwanted. Thanks for the info. Generally apps would not need to know whether to select between 12 and 24? Can't they just use the higher level (and POSIX defined) %X to get the appropriate default? I propose the wiki at least should be reworded to state that am_pm should be omitted only when it doesn't make any sense, like in Finland for example? Also we'll need to fix up some locales that may have blindly followed the existing advice. The 12h format is not appropriate for Ireland at least: $ LC_TIME=en_IE date +'def: %X | 12h: %r | 24h: %T' def: 18:19:52 | 12h: 06:19:52 | 24h: 18:19:52 cheers, Pádraig. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785118: coreutils: date : format %p %P do not work properly
Hi, On 2015-05-12 20:29, Pádraig Brady wrote: On 12/05/15 17:55, Marko Myllynen wrote: On 2015-05-12 18:49, Pádraig Brady wrote: On 12/05/15 16:40, Pádraig Brady wrote: On 12/05/15 14:51, Michael Stone wrote: On Tue, May 12, 2015 at 03:36:17PM +0200, op...@mumm.ac.be wrote: I'm just upgrading my server from debian 7 (wheezy) to debian 8 (jessie) and several of my scripts are not working anymore. After some tests, it turns out that the problem likely comes from the fact the 'date' function does not work as expected. In wheezy, the command line date /bin/date +%Y%m%d.%p would have returned 20150512.PM In jessie, the same command line returns 20150512. omitting PM. As a consequence of this omission, my scripts are crashing. Have you got any idea why this is happening? I can't reproduce it: /bin/date +%Y%m%d.%p 20150512.AM If I had to guess, I'd say it's a locale issue. What does env LANG=C LC_ALL=C /bin/date +%Y%m%d.%p return? If that works, what does locale return when run by itself? %p is blank in many locales unfortunately. You can see the am_pm vary with these commands: $ LC_ALL=en_IE locale -k LC_TIME $ LC_TIME=C locale -k LC_TIME $ LC_ALL=zh_CN.utf8 date +%p 下午 $ LC_ALL=en_US.utf8 date +%p PM $ LC_ALL=en_US date +%p PM locales with blank am_pm should be fixed up to allow one to get an explicit 12 hour format like `date +%I:%m%p` for example. Note some locales (like en_GB for example) default to 24 hour (t_fmt=%T), and also provide an am_pm entry, which is the correct behavior in my opinion. I see that https://sourceware.org/glibc/wiki/Locales states: am_pm and t_fmt_ampm - should be empty if using 24 hour time Marko, that seems incorrect? At least am_pm should be populated to allow users to generate 12 hour time with strftime? I can't find references to the discussion I had with Keld earlier but the rationale for not populating it was along the lines: 1) am_pm should be populated only if AM/PM convention is used to signal applications they should not try to print them when using them is unwanted. Seems that only the locale(5) commit messages, not the page itself, spell this out: http://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/?id=b5d4168adfb426f45108ac2bf7c8b17b126b07a1 http://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/?id=0c2dbad182e40db2ca47128f229ca7dbd83e179f 2) what unwanted means is that in many cases 12 hour time with AM/PM notation is alien thus generating such time representation under those locales would be illogical (e.g. 5.34 ip. in Finnish context is completely unnatural). The same goes for various name_* keywords in LC_NAME, defining them for locales where they are not used would not allow signaling applications that under those locales their usage is unwanted. Thanks for the info. Generally apps would not need to know whether to select between 12 and 24? Can't they just use the higher level (and POSIX defined) %X to get the appropriate default? I propose the wiki at least should be reworded to state that am_pm should be omitted only when it doesn't make any sense that might be a viable option but I think this should be discussed on libc-alpha/libc-locales lists first to allow people there to comment and see if we could even reach consensus. I don't know are there really applications using an empty am_pm to check whether to use 12 or 24 hour time (and if so, would that be a backward compatibility issue) but sounds like by using %X things might be more flexible and portable. Also we'll need to fix up some locales that may have blindly followed the existing advice. No, that's backwards - many/most glibc locales were contributed around '97/'98 or so by people who participated writing the related standards and code, the wiki page has been around only for a couple of years, it aims to document the existing situation and practices to make sure all the locales are consistent and also to make it easier to contribute new locales or validate existing ones. The 12h format is not appropriate for Ireland at least: If I'm not mistaken it has been this way since the locale was added in 1997. In general there's almost no activity at all on glibc locales front so finding issues like this in not totally unexpected. Related to this, it's unclear why the earlier mentioned script has started failing after a distribution upgrade since there certainly haven't been any efforts in upstream to actively remove am_pm or such from locales. Thanks, -- Marko Myllynen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785118: coreutils: date : format %p %P do not work properly
On Tue, May 12, 2015 at 03:36:17PM +0200, op...@mumm.ac.be wrote: I'm just upgrading my server from debian 7 (wheezy) to debian 8 (jessie) and several of my scripts are not working anymore. After some tests, it turns out that the problem likely comes from the fact the 'date' function does not work as expected. In wheezy, the command line date /bin/date +%Y%m%d.%p would have returned 20150512.PM In jessie, the same command line returns 20150512. omitting PM. As a consequence of this omission, my scripts are crashing. Have you got any idea why this is happening? I can't reproduce it: /bin/date +%Y%m%d.%p 20150512.AM If I had to guess, I'd say it's a locale issue. What does env LANG=C LC_ALL=C /bin/date +%Y%m%d.%p return? If that works, what does locale return when run by itself? Mike Stone -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785118: coreutils: date : format %p %P do not work properly
Package: coreutils Version: 8.23-4 Severity: normal Dear Maintainer, I'm just upgrading my server from debian 7 (wheezy) to debian 8 (jessie) and several of my scripts are not working anymore. After some tests, it turns out that the problem likely comes from the fact the 'date' function does not work as expected. In wheezy, the command line date /bin/date +%Y%m%d.%p would have returned 20150512.PM In jessie, the same command line returns 20150512. omitting PM. As a consequence of this omission, my scripts are crashing. Have you got any idea why this is happening? Best regards, Sebastien Legrand *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages coreutils depends on: ii libacl1 2.2.52-2 ii libattr1 1:2.4.47-2 ii libc62.19-18 ii libselinux1 2.3-2 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785118: coreutils: date : format %p %P do not work properly
On 12/05/15 16:40, Pádraig Brady wrote: On 12/05/15 14:51, Michael Stone wrote: On Tue, May 12, 2015 at 03:36:17PM +0200, op...@mumm.ac.be wrote: I'm just upgrading my server from debian 7 (wheezy) to debian 8 (jessie) and several of my scripts are not working anymore. After some tests, it turns out that the problem likely comes from the fact the 'date' function does not work as expected. In wheezy, the command line date /bin/date +%Y%m%d.%p would have returned 20150512.PM In jessie, the same command line returns 20150512. omitting PM. As a consequence of this omission, my scripts are crashing. Have you got any idea why this is happening? I can't reproduce it: /bin/date +%Y%m%d.%p 20150512.AM If I had to guess, I'd say it's a locale issue. What does env LANG=C LC_ALL=C /bin/date +%Y%m%d.%p return? If that works, what does locale return when run by itself? %p is blank in many locales unfortunately. You can see the am_pm vary with these commands: $ LC_ALL=en_IE locale -k LC_TIME $ LC_TIME=C locale -k LC_TIME $ LC_ALL=zh_CN.utf8 date +%p 下午 $ LC_ALL=en_US.utf8 date +%p PM $ LC_ALL=en_US date +%p PM locales with blank am_pm should be fixed up to allow one to get an explicit 12 hour format like `date +%I:%m%p` for example. Note some locales (like en_GB for example) default to 24 hour (t_fmt=%T), and also provide an am_pm entry, which is the correct behavior in my opinion. I see that https://sourceware.org/glibc/wiki/Locales states: am_pm and t_fmt_ampm - should be empty if using 24 hour time Marko, that seems incorrect? At least am_pm should be populated to allow users to generate 12 hour time with strftime? thanks, Pádraig. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
