bug#42470: Help text update suggestion for "date" util

On 7/25/20 8:07 AM, Wes Novack wrote: Thank you! For future reference, what is the PR process? See: https://debbugs.gnu.org/ and look for "read more" if you're interested.

bug#42470: Help text update suggestion for "date" util

Thank you! For future reference, what is the PR process? On Sat, Jul 25, 2020, 8:18 AM Bernhard Voelker wrote: > On 2020-07-21 19:45, Wes Novack wrote: > > Greetings! For the GNU coreutils "date" utility, I would like to suggest > > updating the help text > > &g

bug#42470: Help text update suggestion for "date" util

On 2020-07-21 19:45, Wes Novack wrote: > Greetings! For the GNU coreutils "date" utility, I would like to suggest > updating the help text > > from %s seconds since 1970-01-01 00:00:00 UTC > to %s seconds since the epoch, 1970-01-01 00:00:00 UTC > > This was sugge

bug#42470: Help text update suggestion for "date" util

Greetings! For the GNU coreutils "date" utility, I would like to suggest updating the help text from %s seconds since 1970-01-01 00:00:00 UTC to %s seconds since the epoch, 1970-01-01 00:00:00 UTC This was suggested in this StackOverflow post and has received many (45) upvo

bug#41106: date --date '20180325 02:58:00' fails

tag 41106 notabug thanks On 2020-05-06 10:04, Julien Demaria wrote: >> $ date --date '20180325 02:58:00' >> date: invalid date `20180325 02:58:00' > Sorry I just found the reason in the FAQ... :-( > https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-comm

bug#41106: date --date '20180325 02:58:00' fails

-faq.html#The-date-command-is-not-working-right_002e I am in local daylight saving time change case. Thanks De : Julien Demaria Envoyé : mercredi 6 mai 2020 09:59 À : bug-coreutils@gnu.org Objet : date --date '20180325 02:58:00' fails Hi, We found this very

bug#41106: date --date '20180325 02:58:00' fails

Sorry I just found the reason in the FAQ... :-( https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e I am in local daylight saving time change case. Thanks De : Julien Demaria Envoyé : mercredi 6 mai

bug#41107: date --date '20180325 02:58:00' fails

Hi, We found this very suspect behavior: $ date --date '20180325 02:58:00' date: invalid date `20180325 02:58:00' but for the previous day it works...: $ date --date '20180323 02:58:00' Fri Mar 23 02:58:00 CET 2018 Is it a bug? Adding -u or setting TZ seems a workaround. Tested with version

bug#40958: date command give current time zone regardless of seconds since epoch requested.

ftware/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e And for the timezone and date in question. zdump -v Europe/London | grep 1970 ...no output... That would be a little confusing. So let's look at it with a pager such as less. Browse and find the years of in

bug#40958: date command give current time zone regardless of seconds since epoch requested.

>From : A further inquiry during 1966–1967 led the government of Harold Wilson to introduce the British Standard Time experiment, with Britain remaining on GMT+1 throughout the year. This took place between 27 October 1968 and 31

bug#40586: date and '%-N' does not appear to remove leading zeros anymore, but trailing zeros.

On 4/12/20 1:51 PM, Drake Jacovian wrote: Obviously, removing trailing zeroes will changes it value. %-N is intended to be used after a decimal point, so removing trailing zeros does not change its value in its intended use.

bug#40586: date and '%-N' does not appear to remove leading zeros anymore, but trailing zeros.

Using... date (GNU coreutils) 8.32 uname -a Linux server 4.19.114-1-MANJARO #1 SMP Thu Apr 2 17:04:36 UTC 2020 x86_64 GNU/Linux I have noticed that %-N when used with the data command no longer appears to always remove leading zeros, instead it appears to be removing trailing zeros

bug#40363: date: add Julian day number output format

date(1) should add "Julian day number" or the "Astronomical day number" (see (info "(emacs) Calendar Systems") output format. Else for crontab(5) one must do # Run once per 48 hours (every other day), even across week, month, and year boundaries: 33

bug#40220: date command set linux epoch time failed

On 3/29/20 9:32 PM, Bob Proulx wrote: Both calls from GNU date are returning EINVAL. Those are Linux kernel system calls. Those Linux kernel system calls are using CLOCK_MONOTONIC. OK, I think I understand now. For some reason Linux prohibits you from setting CLOCK_REALTIME to a value less

bug#40220: date command set linux epoch time failed

Paul Eggert wrote: > Bob Proulx wrote: > > By reading the documentation for CLOCK_MONOTONIC in clock_gettime(2): > > GNU 'date' doesn't use CLOCK_MONOTONIC, so why is CLOCK_MONOTONIC relevant > to this bug report? GNU date uses clock_settime() and settimeofday() on my Deb

bug#40220: date command set linux epoch time failed

On 3/28/20 9:12 AM, Bob Proulx wrote: By reading the documentation for CLOCK_MONOTONIC in clock_gettime(2): GNU 'date' doesn't use CLOCK_MONOTONIC, so why is CLOCK_MONOTONIC relevant to this bug report? Is this some busybox thing? If so, user 'shy' needs to report it to the busybox people

bug#40220: date command set linux epoch time failed

rminal. And then in that other terminal logged in as root I try to execute "date -s '1970-01-01 00:00:00 UTC'" as soon as possible. I am never able to do so due to EINVAL. But if I reboot and repeat the experiment trying to set a few seconds in time later then if I am quick I can sometimes c

bug#40220: date command set linux epoch time failed

On 3/27/20 11:52 PM, Bob Proulx wrote: I tested this in a victim system and if I was very quick I was able to log in and set the time to :10 seconds but no earlier. Sounds like some sort of atomic-time thing, since UTC and TAI differed by 10 seconds when they started up in 1972. Perhaps the

bug#40220: date command set linux epoch time failed

tag 40220 + notabug close 40220 thanks shy wrote: > I use command date -s "1970-01-20 00:00:00" to set date, but it > failed. there is error message "date: can't set date: Invalid > argument". > It's UTC time and no timezone. This is most likely a l

bug#40220: date command set linux epoch time failed

Hi all: I use command date -s "1970-01-20 00:00:00" to set date, but it failed. there is error message "date: can't set date: Invalid argument". It's UTC time and no timezone. I test with stime or settimeofday to set seconds 0, they are all have the problem.

bug#39205: date -d '...' should support superset of POSIX 'at' dates

On today's Austin Group meeting, the question of whether some form of 'date -d "..."' should be specified. While there is no way that POSIX would standardize everything that GNU date can parse, there was an idea that supporting '@seconds' since Epoch, plus all of the formats already

bug#38780: date: next feb 11

date -d should add a way to say "next feb 11" or "next 2/11" etc. E.g., at(1) knows we are always talking about the coming Feb. 11, and not the one that has already passed in the current year. Just like we can say "next Friday" and "last Friday" currently.

bug#38003: date --date=-1month gives same month today

Subtracting 1 month from October 31st results in September 31st. Since the date doesn't exist, it is normalized: September 31st is "one day after September 30th", which results in October 1st. Thanks for explanation. To me it makes more sense that going one month back from 31 oct, o

bug#38003: date --date=-1month gives same month today

tag 38003 notabug close 38003 stop Hello, On 2019-10-31 2:34 a.m., Ilja Honkonen wrote: Please CC me as I'm not on this list. Running date (GNU coreutils) 8.26 on fedora 30 today (date --utc  -I: 2019-10-31) with --date=-1month gives the same month which doesn't make sense: $ date --utc -I

bug#38003: date --date=-1month gives same month today

t;now" is the 1st of the month. If I understand correctly, you would prefer that on March 29th, 30th, and 31st, this command would return the same date (except on leap years)? $ date --date=-1month +"%m-%d" 02-28 This would introduce one to three discontinuities per month, but the calcula

bug#38003: date --date=-1month gives same month today

Hello Please CC me as I'm not on this list. Running date (GNU coreutils) 8.26 on fedora 30 today (date --utc -I: 2019-10-31) with --date=-1month gives the same month which doesn't make sense: $ date --utc -I --date=-1month 2019-10-01 I assume using --date=-31day also wouldn't work if run e.g

bug#37921: date -d "a day ago" differs from date -d "1 day ago"

tag 37921 notabug thanks On 2019-10-25 18:23, Matt Carter wrote: > Thank you, Eric and Berny, for the explanation. > I'm glad to see it's intentional. Thanks for teaching me about the military > time zones. Thanks for the feedback. I'm hereby closing this issue in our bug tracker as "not a

bug#37961: Bug report of date commond

On 10/28/19 12:34 AM, zhangzhi...@mail.iap.ac.cn wrote: ~>date -d "1940-06-01" +"%Y-%m-%d" date: invalid date ‘1940-06-01’ Presumably your TZ setting is Asia/Shanghai, as I see the symptoms as follows: $ TZ=Asia/Shanghai date -d "1940-06-01" +"%Y

bug#37961: Bug report of date commond

Mr. maintainers: Hello! I am very glad to write this email to report my problem. When I am running commond on my server： ~>date -d "1940-06-01" +"%Y-%m-%d" date: invalid date ‘1940-06-01’ but the other commond works right： sense3:~>date -d '1939-06-

bug#37921: date -d "a day ago" differs from date -d "1 day ago"

Thank you, Eric and Berny, for the explanation. I'm glad to see it's intentional. Thanks for teaching me about the military time zones. -Matt

bug#37921: date -d "a day ago" differs from date -d "1 day ago"

On 10/25/19 8:59 AM, Matt Carter wrote: When I ask date(1) for the date "a day ago", I get a different result from when I ask date(1) for the date "1 day ago". The results differ by 3 hours. If I ask for UTC time, the results differ by 1 hour. I'm not able to find an

bug#37921: date -d "a day ago" differs from date -d "1 day ago"

On 2019-10-25 15:59, Matt Carter wrote: > + date -d 'a day ago' Please look at the output with --debug. $ date --debug -d 'a day ago' date: parsed zone part: UTC-01 [...] The first 'a' is not parsed [1] as a synonym for "one day", but rather as the "A" mil

bug#37921: date -d "a day ago" differs from date -d "1 day ago"

When I ask date(1) for the date "a day ago", I get a different result from when I ask date(1) for the date "1 day ago". The results differ by 3 hours. If I ask for UTC time, the results differ by 1 hour. I'm not able to find anything in the manual to explain this differen

bug#37060: bug in date / coreutils

I think that bug was fixed in 2017, and your coreutils version 8.23 predates the fix. I suggest upgrading to the current version (8.31) of coreutils, as 8.23 is pretty old anyway.

bug#37060: bug in date / coreutils

Hi, I believe there is a bug in the date utility. My system is set to Berlin time, now daylight saving time. When I put in date --date='TZ="Europe/Berlin" now' I get correctly Sat 17 Aug 05:11:18 CEST 2019 However, putting in   date --date='TZ="America/Los_Angeles"

bug#35632: date Parse of '13:00 + 2 hours' Broken.

tag 35632 notabug close 35632 stop Hello, (sorry for the delayed reply) On Wed, May 08, 2019 at 12:57:10PM +0100, Ralph Corderoy wrote: > > Using date from coreutils 8.31-1 on Arch Linux. > This surprised me. > > $ TZ=UTC0 /bin/date -d '1pm + 2 hours' > Wed 8 May

bug#36383: date command processes timezone differently when doing math

tag 36383 notabug close 36383 stop Hello, On Tue, Jun 25, 2019 at 04:10:07PM -0700, Brian Woods wrote: > When doing a math operation to a date command it appear to process the > timezone differently. [...] > > #echo $datNow > 2019-06-25 15:21:34 > > #date -d "$datNow +

bug#36383: date command processes timezone differently when doing math

When doing a math operation to a date command it appear to process the timezone differently. The system is Ubuntu 18.04.2 LTS. Versions: coreutils/bionic,now 8.28-1ubuntu1 amd64 [installed] #echo $datNow 2019-06-25 15:21:34 #date -d "$datNow " "+%Y-%m-%d %H:%M:%S" --debug da

bug#14703: stat(1) Linux creation date support

close 14703 stop On 21/05/19 18:35, Zoran Dželajlija wrote: > reopen 14703 > thanks > > Hi, > > - support for statx() syscall was added to Linux kernel 4.11 (in 2017), >says statx(2) man page at http://man7.org/linux/man-pages/man2/statx.2.html >and it also says that > > - support

bug#14703: stat(1) Linux creation date support

reopen 14703 thanks Hi, - support for statx() syscall was added to Linux kernel 4.11 (in 2017), says statx(2) man page at http://man7.org/linux/man-pages/man2/statx.2.html and it also says that - support for statx() was added to glibc 2.28 (released Aug 2018) please consider fixing

bug#35632: date Parse of '13:00 + 2 hours' Broken.

Hi, Using date from coreutils 8.31-1 on Arch Linux. This surprised me. $ TZ=UTC0 /bin/date -d '1pm + 2 hours' Wed 8 May 15:00:00 UTC 2019 $ TZ=UTC0 /bin/date -d '13:00 + 2 hours' Wed 8 May 12:00:00 UTC 2019 The documentation doesn't suggest `1pm' and `13:00' are treated

bug#35336: date should respect TIME_STYLE too

積丹尼 Dan Jacobson wrote: All the other utilities respect the environment variable ‘TIME_STYLE’, except date(1) itself! Date should be no different... I don't think I agree. In hindsight, that environment variable was a mistake and we shouldn't let the mistake propagate elsewhere. Standard

bug#35336: date should respect TIME_STYLE too

All the other utilities respect the environment variable ‘TIME_STYLE’, except date(1) itself! Date should be no different...

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

On Tue, Apr 16, 2019 at 1:37 PM Assaf Gordon wrote: > Thank you both for testing. > > So, to summarize: > whenever "inv-year" fails - it is a problem with glibc on your > setup, *not* a problem in coreutils' date(1) program. > > If there is a setup where "

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

tm (after adjustment) = 0009-04-16 00:43:28 (mday=16 wday=2, isdst=0) mktime() after date adjustment = -61874061392 So: a pristine 19.04 runs it. My laptop (which is my work machine, full of other packages & programs), does not. Thank you both for testi

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

It has to be something messing/interacting with coreutils/date on 19.04 (and probably on Tumbleweed). I created a new container with 19.04, and then: * apt build-dep coreutils * apt install rsync wget git * git clone git://git.sv.gnu.org/coreutils * cd coreutils * export FORCE_UNSAFE_CONFIGURE=1

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

leweed from latest > > git: > > > >$ src/date --debug '+%-Y' -d '- 2010 years' > [....] > >date: error: adding relative date resulted in an invalid date: '(Y-M-D) > > 0009-04-15 22:10:37' > > This makes it easy to pinpoint (hooray for "--deb

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

On 4/15/19 9:41 PM, Assaf Gordon wrote: > A good starting point is adding the "--debug" option to date(1) > and examining its output. Hi Assaf, I can easily reproduce here on my regular openSUSE:Tumbleweed from latest git: $ src/date --debug '+%-Y' -d '- 2010 years' date:

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

/coreutils$ date +%-Y -d '- 2010 years' date: invalid date ‘- 2010 years’ 1 cerdea@piatam:/data/buildd/coreutils$ date --version date (GNU coreutils) 8.30 [...] On Mon, Apr 15, 2019 at 12:16 PM O. Emmerson wrote: $ file /bin/date /bin/date: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

I have ran a few tests on Ubuntu 16.04, 18.04, 18.10, and 19.04 (all X86_64): 16.04: root@u1604:~# date +%-Y -d '- 2010 years' 9 root@u1604:~# date --version date (GNU coreutils) 8.25 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

$ file /bin/date /bin/date: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=26fa7f6c43c354d8c5647ebf946255a2b8e3c53d, stripped

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

I have downloaded and compiled 8.31 from source to see if it makes any difference and have gotten the same error.

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

On 15/04/2019 17:02, GNU bug Tracking System wrote: It works for me with coreutils 8.31 on RHEL 7 x86-64: $ date +%-Y -d "- 2010 years" 9 Most likely you are running on a 32-bit machine, and dates in the year 9 cannot be represented in a 32-bit timestamp. So a simple fix would

bug#35289: date+%-Y -d "- N years" errors when N > 111

On 4/15/19 7:57 AM, O. Emmerson wrote: > I have been using 'date +%-Y -d "- 2010 years" in a script for years but > today after using the script after upgrading to Ubuntu 19.04 it has > failed. It works for me with coreutils 8.31 on RHEL 7 x86-64: $ date +%-Y -d "- 20

bug#35289: date+%-Y -d "- N years" errors when N > 111

I have been using 'date +%-Y -d "- 2010 years" in a script for years but today after using the script after upgrading to Ubuntu 19.04 it has failed. After some experimentation it succeeds with upto 111 years but fails from 112 onwards. Error given is: 'date: invalid date '-

bug#35078: Possible bug in the date command, to do with %p

' library, has an option (which one can use in Conky, actually) to convert output to all uppercase - thus achieving what I desired. 'Date' could implement something similar. Yours Nicholas On 03/04/2019 04:08, Eric Blake wrote: > On 4/2/19 3:22 PM, Nicholas Joll wrote: > >> I have two sug

bug#35109: date 'tomorrow' bug

tags 35109 notabug close 35109 stop Hello, On 2019-04-02 7:23 a.m., Maximilian Gleißner wrote: I have encountered a possible bug with the date function using both SuSE LEAP 15.0 and SuSE 10.2. This bug occurs when asking date for 'tomorrow' when there is a daylight saving timechange

bug#35109: date 'tomorrow' bug

On 4/2/2019 6:23 AM, Maximilian Gleißner wrote: > Hi, > > I have encountered a possible bug with the date function using both SuSE > LEAP 15.0 and SuSE 10.2. > This bug occurs when asking date for 'tomorrow' when there is a daylight > saving timechange. > > Note

bug#35109: date 'tomorrow' bug

Hi, I have encountered a possible bug with the date function using both SuSE LEAP 15.0 and SuSE 10.2. This bug occurs when asking date for 'tomorrow' when there is a daylight saving timechange. Note: The machine is located in the GMT+1 timezone, and daylight savings time changed on 31.03.2019

bug#35032: date ISO 8601 / RFC 3339 formats

Le jeudi 28 mars 2019 à 22:07 +0100, Erik Auerswald a écrit : > > > 1. The W3C profile mandates T as time separator, and ":" as > > hour/minutes separator > > 2. RFC 3339 makes both optional > > > > Then, logically, date removed the ":" for

bug#35032: date ISO 8601 / RFC 3339 formats

specifically. Can you > say exactly what you want, with specific calls to 'date' and what you > want the output to look like, and why? Sadly, you stripped too much of the original mail. I'll repeat the relevant parts of that mail: On Thu, Mar 28, 2019 at 06:20:14PM +0100, Nicolas Mailhot wro

bug#35032: date ISO 8601 / RFC 3339 formats

severity 35032 wishlist retitle 35032 date: adjust rfc8601/3339 formats to W3C standard stop On 2019-03-28 11:20 a.m., Nicolas Mailhot wrote: Would it be possible to make them both optional in --rfc-3339, and both mandatory in --iso-8601 ? Or add a --w3c option that conforms to the W3C profile

bug#35032: date ISO 8601 / RFC 3339 formats

On 3/28/19 10:20 AM, Nicolas Mailhot wrote: > Would it be possible to make them both optional in --rfc-3339, and > both mandatory in --iso-8601 ? Sorry, I don't understand what you're proposing, specifically. Can you say exactly what you want, with specific calls to 'date' and what yo

bug#34608: date +%+4C is unimplemented, contrary to POSIX

aul Eggert Date: Sun, 24 Feb 2019 23:35:23 -0800 Subject: [PATCH 1/3] build: update gnulib submodule to latest --- gnulib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gnulib b/gnulib index e3970fb98..188d87b05 16 --- a/gnulib +++ b/gnulib @@ -1 +1 @@ -Subproject com

bug#34608: date +%+4C is unimplemented, contrary to POSIX

On 2/21/19 10:01 PM, Paul Eggert wrote: > Eric Blake wrote: >> That used to be true, but now POSIX wants date to behave as if it uses >> strftime: >> >> http://austingroupbugs.net/view.php?id=466 > > Ah, I didn't know that. Is there a list of recent changes

bug#34608: date +%+4C is unimplemented, contrary to POSIX

Eric Blake wrote: That used to be true, but now POSIX wants date to behave as if it uses strftime: http://austingroupbugs.net/view.php?id=466 Ah, I didn't know that. Is there a list of recent changes to the POSIX spec for strftime somewhere? I can look to see which of them have made

bug#34608: date +%+4C is unimplemented, contrary to POSIX

On 2/21/19 9:37 PM, Paul Eggert wrote: > Eric Blake wrote: > >> date -d 0001-01-01 +.%+4C. >> >> should produce ".+000.", but currently it produces ".%+4C." because the >> + flag is unimplemented. >> >> See also http://austingroupbug

bug#34608: date +%+4C is unimplemented, contrary to POSIX

Eric Blake wrote: date -d 0001-01-01 +.%+4C. should produce ".+000.", but currently it produces ".%+4C." because the + flag is unimplemented. See also http://austingroupbugs.net/view.php?id=1184 Surely this bug should be reported against strftime, not against 'date'.

bug#34608: date +%+4C is unimplemented, contrary to POSIX

POSIX requires the '+' flag in %C to output padding with leading 0, and additionally to add a +/- indicator if the minimum field width is larger than 2 bytes. Thus: date -d 0001-01-01 +.%+4C. should produce ".+000.", but currently it produces ".%+4C." because the + flag is

bug#9614: date ignoring wrong TZ values

Assaf Gordon wrote: gnulib's tzalloc implementation should be greatly expanded to be able to decode the operating system's local timezome? (or perhaps the timezone management code copied from glibc?) That's what I was thinking of, except that it'd be better to extend glibc to support tzalloc

bug#9614: date ignoring wrong TZ values

should fix tzalloc so it does. Once that happens, 'date' can simply call tzalloc (getenv ("TZ")) to see whether the time zone setting is OK. Thanks for the feedback. Asking for a bit more details, clarifications... If I understand correctly, the current gnulib implementation of "t

bug#9614: date ignoring wrong TZ values

I think this implementation is heading in the wrong direction. To determine whether a time zone string FOO is valid, a program should call tzalloc (FOO) and sees whether that yields NULL. And if tzalloc doesn't work that way now, we should fix tzalloc so it does. Once that happens, 'date' can

bug#9614: date ignoring wrong TZ values

ly means that with "--debug" it might warn about invalid timezone when it is a valid timezone that resolves to GMT). OpenBSD is such a case. --- With this patch, "date --debug" is able to warn about: TZ=America/NewYorx date --debug TZ=Europe/Lomdom date --debug TZ=FOOBA

bug#33221: date command + 1 month

Thanks for the tip! Saludos, Nicolás Flores @fosnss El mié., 31 de oct. de 2018 a la(s) 20:27, Assaf Gordon ( assafgor...@gmail.com) escribió: > tags 33221 notabug > close 33221 > stop > > Hello, > > On 2018-10-31 5:08 p.m., Nicolás Flores wrote: > > Date Bug detect

bug#33221: date command + 1 month

tags 33221 notabug close 33221 stop Hello, On 2018-10-31 5:08 p.m., Nicolás Flores wrote: Date Bug detected: Wed Oct 31 17:02:41 CST 2018 when executing # *date +%b* Result: *Oct * This is Ok, but... # *date +%b -d '+1 month'* Result: *Dec* Jump in the month of *November* Indeed

bug#33221: date command + 1 month

Date Bug detected: Wed Oct 31 17:02:41 CST 2018 when executing # *date +%b* Result: *Oct * This is Ok, but... # *date +%b -d '+1 month'* Result: *Dec* Jump in the month of *November* @fosnss

bug#29589: date %k adds extra space for single digits hours

tags 29589 notabug close 29589 stop (triaging old bugs) From: Bishop Bettini [mailto:bishop.bett...@gmail.com] On Wed, Dec 6, 2017 at 4:17 AM, Noam Arad wrote: When using date command with the format %k if the hour is single digits there is an extra space added. E.g.: date -u +"%Y/%m/

bug#25554: date to support iso-8601 week-format (patch included)

retitle 25554 date: add iso-8601 week-format option severity 25554 wishlist tags 25554 wontfix patch close 25554 stop (triaging old bugs) On 2017-01-27 3:22 p.m., Paul Eggert wrote: I dunno, there are several ISO 8601 formats that 'date -I' doesn't have a special case for now; why add

bug#22397: Date -- Format arithemtic yields unexpected results

tags 22397 notabug close 22397 stop (triaging old bugs) On 18/01/16 07:16 AM, Pádraig Brady wrote: On 18/01/16 03:53, Adam Danischewski wrote: $> date Sun Jan 17 22:49:40 EST 2016 $> date -d"04:00" Sun Jan 17 04:00:00 EST 2016 $> date -d"04:00 +1 day" Sun Jan

bug#13938: Bug: date(1) -d "relative-to-skipped-time" problem (also in touch(1) -d)

close 13938 stop (triaging old bugs) On 12/03/13 11:23 PM, Bob Proulx wrote: Aleš Kantor wrote: Set date to Mar 10, 2013 (the day clocks moved fwd) In which timezone? Please tell us what timezone you are in because the tzdata is different for everyone. Instead of setting the time simply

bug#13058: European date format

close 13058 stop (triaging old bugs) On 02/12/12 02:42 PM, Bob Proulx wrote: Ohad Basan wrote: Regarding 'date' command. the -d parameter doesn't know how to receive a european date format e.g. DD/MM/ I am assuming by "doesn't know how to receive" you mean it produces a

bug#12650: Bug in date command

close 12650 stop (triaging old bugs) On 14/10/12 05:28 PM, Bob Proulx wrote: Thiago Picharski wrote: I'm trying run this command "date -d 12-10-21", but occur the follow error, date: invalid date "12-10-21" and finalize with error code 1. [...] The basic problem is that

bug#16782: Insensitive behavior in date when given invalid fomatting string

severity 16782 wishlist retitle 16782 date: reject invalid %[X] format characters stop (triaging old bugs) Hello, On 17/02/14 10:42 AM, f...@fuz.su wrote: Consider the following set of date invocations: $ date +%05 00%05 $ date +%Y%#05 20140%#05 $ date +x%7 x

bug#14725: Documentation Bug: date

tags 14725 fixed close 14725 stop (triaging old bugs) Hello, Jon Hartman wrote: Should the -I (capital I) not be listed in the documentation? This has historically presented the international format. It seems your message was lost and never replied to. Sorry about that. In the meantime

bug#14703: stat no creation date on ntfs filesystem files which have creation dates

tags 14703 notabug close 14703 stop (triaging old bugs) Hello, On 24/06/13 03:12 PM, Pádraig Brady wrote: On 06/24/2013 03:57 PM, Enda wrote: When I use stat, there is no creation date on ntfs filesystem files which have creation dates: $ stat file.txt ... So the issue here

bug#18328: can't say date -d '8pm -0500' though other combos work

AG> I hope to get to this bug soon. Good.

bug#18328: can't say date -d '8pm -0500' though other combos work

tags 18328 confirmed retitle 18328 date: '8pm -0500' is invalid (am/pm problem) stop (triaging old bugs) Hello, On 25/08/14 10:01 AM, 積丹尼 Dan Jacobson wrote: $ date -d '8pm -0500' date: invalid date ‘8pm -0500’ <--why can't this combo work? This is indeed a bug (specifically in gnuli

bug#17161: date: confusing: "TIME -/+NUM" treated as time zone

severity 17161 wishlist retitle 17161 date: confusing: "TIME -/+NUM" treated as time zone stop (triaging old bugs) Hello, On 02/04/14 05:27 AM, Eric Blake wrote: On 04/02/2014 02:17 AM, Marc R.J. Brevoort wrote: The more days I subtract, the more hours are added. If this were a

bug#14545: date --iso-8601 should use colon in time zone offset

tags 14545 fixed close 14545 stop (triaging old bugs) This was fixed in: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=17bbf6ce44eb543a95695fa9d2cbd70fb52c6f42 Marking as "fixed" and closing. -assaf

bug#11115: linux date arithmetic

tags 5 notabug close 5 stop (triaging old bugs) Hello, On 28/03/12 06:39 AM, Stefan Karamuz wrote: Please check the 2 linux commands: date -d "$(date +%F\ %H:%M:%S)" +%F\ %H:%M:%S date -d "$(date +%F\ %H:%M:%S) + 1 minute" +%F\ %H:%M:%S It's very confusing,

bug#9614: date ignoring wrong TZ values

tags 9614 wontfix severity 9614 wishlist retitle 9614 date: warn on invalid TZ string (was: date ignoring wrong TZ values) stop (triaging old bugs) Hello, On 27/09/11 11:48 PM, Paul Eggert wrote: On 09/27/11 22:44, Sandro Santilli wrote: A warning/error message with hint on how

bug#7257: [PATCH] Correct typos in date

tags 7257 fixed close 7257 stop (Triaging old bugs) Hello, On 17/04/11 03:04 AM, Jim Meyering wrote: Tobias Quathamer wrote: I think I've found three typos in the date program. I've attached a patch correcting those. There was some discussion at http://debbugs.gnu.org/7257 and one change

bug#32288: date(1) Produces ISO 8601 it Won't Take Back.

On 07/27/2018 04:34 AM, Ralph Corderoy wrote: > $ date -uIs -d @-62135596801 > -12-31T23:59:59+00:00 > $ date -uIs -d @-12-31T23:59:59+00:00 > date: invalid date ‘@-12-31T23:59:59+00:00’ > $ > > If date thinks it'

bug#32288: date(1) Produces ISO 8601 it Won't Take Back.

Hi, coreutils 8.29-1 on Arch Linux. $ date -uIs -d @-62135596801 -12-31T23:59:59+00:00 $ date -uIs -d @-12-31T23:59:59+00:00 date: invalid date ‘@-12-31T23:59:59+00:00’ $ If date thinks it's valid ISO 8601 when it outputs it, I'd

bug#30795: Issue with date command and EDT

On 03/15/2018 12:15 AM, Assaf Gordon wrote: Technically it's an easy fix (patch attached), but it changes a long-standing behavior. Yes, that's a problem. Perhaps we should take the last unit requested in the output format, divide that by two, and add that to the time instead. If the output

bug#30795: Issue with date command and EDT

On 15/03/18 00:15, Assaf Gordon wrote: > Hello, > > On Wed, Mar 14, 2018 at 05:22:04PM -0700, Paul Eggert wrote: >> On 03/13/2018 06:42 PM, Assaf Gordon wrote: >>> Therefore it is always recommended to use noon (12pm) >>> as explicit time when adjusting days

bug#30795: Issue with date command and EDT

Hello, On Wed, Mar 14, 2018 at 05:22:04PM -0700, Paul Eggert wrote: > On 03/13/2018 06:42 PM, Assaf Gordon wrote: > >Therefore it is always recommended to use noon (12pm) > >as explicit time when adjusting days > > Maybe "date" should default to 12:00 in

bug#30795: Issue with date command and EDT

On 03/13/2018 06:42 PM, Assaf Gordon wrote: Therefore it is always recommended to use noon (12pm) as explicit time when adjusting days Maybe "date" should default to 12:00 instead of to 00:00 when the time is not specified? That would avoid this sort of problem, typically.

bug#30795: Issue with date command and EDT

Hello, On 2018-03-13 09:20 AM, Jared Chagnon wrote: I setup a test script: #/bin/bash echo "`date`" echo "`date +%z`" currentdate=`date +%Y%m%d_%H%M%S` echo "current date: $currentdate" olddate=`date "+%Y%m%d_%H%M%S" --date='4 days ago'` echo "

bug#22183: date returns incorrect string for Wednesday in Marathi

On 03/13/2018 02:34 PM, Rafal Luzynski wrote: Please close this bug report Thanks for checking; closing.

<    1   2   3   4   5   6   7   8   9   10   >