Bug#870567: date: day sequence modifiers of month appear to be wrong
Ah, okay, thanks for the info. On Wed, Aug 02, 2017 at 06:48:39PM -0600, Bob Proulx wrote: > Dale Harris wrote: > > Package: coreutils > > Version: 8.26-3 > > Severity: normal > > Tags: upstream > > > > Dear Maintainer, > > > > > > Just trying to figure out what the first, second, third days are of a month. > > > > So for August 2017: > > > > > > August 2017 > > Su Mo Tu We Th Fr Sa > >1 _2 3 4 5 > > 6 7 8 9 10 11 12 > > 13 14 15 16 17 18 19 > > 20 21 22 23 24 25 26 > > 27 28 29 30 31 > > > > > > This is relative to: Wed Aug 2 17:33:10 EDT 2017 > > > > If do: > > > > date -d 'first monday', I get: Mon Aug 7 00:00:00 EDT 2017 > > The docs say: > > The explicit mention of a day of the week will forward the date (only if > necessary) to reach that day of the week in the future. > >Days of the week may be spelled out in full: ‘Sunday’, ‘Monday’, > ‘Tuesday’, ‘Wednesday’, ‘Thursday’, ‘Friday’ or ‘Saturday’. Days may be > abbreviated to their first three letters, optionally followed by a > period. The special abbreviations ‘Tues’ for ‘Tuesday’, ‘Wednes’ for > ‘Wednesday’ and ‘Thur’ or ‘Thurs’ for ‘Thursday’ are also allowed. > >A number may precede a day of the week item to move forward > supplementary weeks. It is best used in expression like ‘third monday’. > In this context, ‘last DAY’ or ‘next DAY’ is also acceptable; they move > one week before or after the day that DAY by itself would represent. > > Therefore mentioning "1 Monday" (which is what "first monday" is > mapped to) will forward to one Monday in the future. Okay. > > > date -d 'second monday', I get: Mon Aug 7 00:00:01 EDT 2017 > > The word "second" is problematic. The documentation says: > >A few ordinal numbers may be written out in words in some contexts. > This is most useful for specifying day of the week items or relative > items (see below). Among the most commonly used ordinal numbers, the > word ‘last’ stands for -1, ‘this’ stands for 0, and ‘first’ and ‘next’ > both stand for 1. Because the word ‘second’ stands for the unit of time > there is no way to write the ordinal number 2, but for convenience > ‘third’ stands for 3, ‘fourth’ for 4, ‘fifth’ for 5, ‘sixth’ for 6, > ‘seventh’ for 7, ‘eighth’ for 8, ‘ninth’ for 9, ‘tenth’ for 10, > ‘eleventh’ for 11 and ‘twelfth’ for 12. > > The important part is: > > Because the word ‘second’ stands for the unit of time > there is no way to write the ordinal number 2 > > That is why you can't say "second monday". You can only use the > numbers and say "2 Monday". (Don't shoot me. I am only the > messenger.) > > > date -d 'third monday', I get: Mon Aug 21 00:00:00 EDT 2017 > > date -d 'fourth monday', I get: Mon Aug 28 00:00:00 EDT 2017 > > date -d 'fifth monday', I get: Mon Sep 4 00:00:00 EDT 2017 > > All okay. > > I want to note that the default date format for legacy reasons is > ambiguous. It is better to use an unambiguous format such as date -R > which will specify the timezone in a standard format. > > > So I'm a bit confused, if it's relative from the day, I could unstand the > > first Monday being the 7th, but the second Monday should be the 14th. If it > > is inside the month, then this doesn't make any sense because the 7th is the > > first Monday of the month, and 14th the second. What am I missing? > > If doing date calculations it is highly recommended to do them around > 12:00 noon instead of midnight to avoid daylight saving time changes. > Let me specify a timezone explicitly here for the archive and > reproducibility of the case. > > env TZ=US/Mountain date -R -d '1 monday 12:00' > Mon, 07 Aug 2017 12:00:00 -0600 > > env TZ=US/Mountain date -R -d '2 monday 12:00' > Mon, 14 Aug 2017 12:00:00 -0600 > > env TZ=US/Mountain date -R -d '3 monday 12:00' > Mon, 21 Aug 2017 12:00:00 -0600 > > env TZ=US/Mountain date -R -d '4 monday 12:00' > Mon, 28 Aug 2017 12:00:00 -0600 > > Or with with UTC instead. Working with UTC is always recommended. > > date -u -R -d '1 monday' > Mon, 07 Aug 2017 00:00:00 + > > date -u -R -d '2 monday' > Mon, 14 Aug 2017 00:00:00 + > > date -u -R -d '3 monday' > Mon, 21 Aug 2017 00:00:00 + > > date -u -R -d '4 monday' > Mon, 28 Aug 2017 00:00:00 + > > A reference to some of these problem areas. > > > https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e > > Hopefully this explains the problem. > Bob -- Dale Harris / Unix System Admin / Generic Network Systems, LLC d...@gnetsys.net +1-212-268-4722 ext. 230 http://www.gnetsys.com/
Bug#870567: date: day sequence modifiers of month appear to be wrong
Dale Harris wrote: > Package: coreutils > Version: 8.26-3 > Severity: normal > Tags: upstream > > Dear Maintainer, > > > Just trying to figure out what the first, second, third days are of a month. > > So for August 2017: > > > August 2017 > Su Mo Tu We Th Fr Sa >1 _2 34 5 > 6 7 8 9 10 11 12 > 13 14 15 16 17 18 19 > 20 21 22 23 24 25 26 > 27 28 29 30 31 > > > This is relative to: Wed Aug 2 17:33:10 EDT 2017 > > If do: > > date -d 'first monday', I get: Mon Aug 7 00:00:00 EDT 2017 The docs say: The explicit mention of a day of the week will forward the date (only if necessary) to reach that day of the week in the future. Days of the week may be spelled out in full: ‘Sunday’, ‘Monday’, ‘Tuesday’, ‘Wednesday’, ‘Thursday’, ‘Friday’ or ‘Saturday’. Days may be abbreviated to their first three letters, optionally followed by a period. The special abbreviations ‘Tues’ for ‘Tuesday’, ‘Wednes’ for ‘Wednesday’ and ‘Thur’ or ‘Thurs’ for ‘Thursday’ are also allowed. A number may precede a day of the week item to move forward supplementary weeks. It is best used in expression like ‘third monday’. In this context, ‘last DAY’ or ‘next DAY’ is also acceptable; they move one week before or after the day that DAY by itself would represent. Therefore mentioning "1 Monday" (which is what "first monday" is mapped to) will forward to one Monday in the future. Okay. > date -d 'second monday', I get: Mon Aug 7 00:00:01 EDT 2017 The word "second" is problematic. The documentation says: A few ordinal numbers may be written out in words in some contexts. This is most useful for specifying day of the week items or relative items (see below). Among the most commonly used ordinal numbers, the word ‘last’ stands for -1, ‘this’ stands for 0, and ‘first’ and ‘next’ both stand for 1. Because the word ‘second’ stands for the unit of time there is no way to write the ordinal number 2, but for convenience ‘third’ stands for 3, ‘fourth’ for 4, ‘fifth’ for 5, ‘sixth’ for 6, ‘seventh’ for 7, ‘eighth’ for 8, ‘ninth’ for 9, ‘tenth’ for 10, ‘eleventh’ for 11 and ‘twelfth’ for 12. The important part is: Because the word ‘second’ stands for the unit of time there is no way to write the ordinal number 2 That is why you can't say "second monday". You can only use the numbers and say "2 Monday". (Don't shoot me. I am only the messenger.) > date -d 'third monday', I get: Mon Aug 21 00:00:00 EDT 2017 > date -d 'fourth monday', I get: Mon Aug 28 00:00:00 EDT 2017 > date -d 'fifth monday', I get: Mon Sep 4 00:00:00 EDT 2017 All okay. I want to note that the default date format for legacy reasons is ambiguous. It is better to use an unambiguous format such as date -R which will specify the timezone in a standard format. > So I'm a bit confused, if it's relative from the day, I could unstand the > first Monday being the 7th, but the second Monday should be the 14th. If it > is inside the month, then this doesn't make any sense because the 7th is the > first Monday of the month, and 14th the second. What am I missing? If doing date calculations it is highly recommended to do them around 12:00 noon instead of midnight to avoid daylight saving time changes. Let me specify a timezone explicitly here for the archive and reproducibility of the case. env TZ=US/Mountain date -R -d '1 monday 12:00' Mon, 07 Aug 2017 12:00:00 -0600 env TZ=US/Mountain date -R -d '2 monday 12:00' Mon, 14 Aug 2017 12:00:00 -0600 env TZ=US/Mountain date -R -d '3 monday 12:00' Mon, 21 Aug 2017 12:00:00 -0600 env TZ=US/Mountain date -R -d '4 monday 12:00' Mon, 28 Aug 2017 12:00:00 -0600 Or with with UTC instead. Working with UTC is always recommended. date -u -R -d '1 monday' Mon, 07 Aug 2017 00:00:00 + date -u -R -d '2 monday' Mon, 14 Aug 2017 00:00:00 + date -u -R -d '3 monday' Mon, 21 Aug 2017 00:00:00 + date -u -R -d '4 monday' Mon, 28 Aug 2017 00:00:00 + A reference to some of these problem areas. https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e Hopefully this explains the problem. Bob
Bug#870567: date: day sequence modifiers of month appear to be wrong
Package: coreutils Version: 8.26-3 Severity: normal Tags: upstream Dear Maintainer, Just trying to figure out what the first, second, third days are of a month. So for August 2017: August 2017 Su Mo Tu We Th Fr Sa 1 _2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 This is relative to: Wed Aug 2 17:33:10 EDT 2017 If do: date -d 'first monday', I get: Mon Aug 7 00:00:00 EDT 2017 date -d 'second monday', I get: Mon Aug 7 00:00:01 EDT 2017 date -d 'third monday', I get: Mon Aug 21 00:00:00 EDT 2017 date -d 'fourth monday', I get: Mon Aug 28 00:00:00 EDT 2017 date -d 'fifth monday', I get: Mon Sep 4 00:00:00 EDT 2017 So I'm a bit confused, if it's relative from the day, I could unstand the first Monday being the 7th, but the second Monday should be the 14th. If it is inside the month, then this doesn't make any sense because the 7th is the first Monday of the month, and 14th the second. What am I missing? -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE= (charmap=UTF-8), LANGUAGE= (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-3+b1 ii libattr1 1:2.4.47-2+b2 ii libc62.24-12 ii libselinux1 2.6-3+b2 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information
