bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

a > revised argument, an appeal to ISO 8601. > > My essential question is this: What is the "proper" time *display format* > for "UTC"? > My personal preference? @%s%N My second preference? %F,%T%N That said, I don't think TZ=UTC (or equivalently date -

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

On 8/26/25 08:43, James Feeney wrote: Your definition of "longstanding" seems a bit disingenuous, since this change, from the default POSIX `date -u` 24 hour format to the 12 hour format, was made in 2020 ? No it wasn't. I just now ran 'date -u' from the coreutils

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

On Mon, 2025-08-25 at 15:20 -0700, Paul Eggert wrote: > > > > Are you inclined to accept the time format of ISO 8601 for the display of > > UTC - or no? > > We should not change the behavior of plain 'date -u' based on any > arguments presented so far in

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

On 2025-08-25 14:15, James Feeney via GNU coreutils Bug Reports wrote: For anyone inclined to accept my appeal to ISO 8601, the current display format returned by `date -u`, especially within the USA, is wrong, and that is a bug that needs to be fixed. Are you inclined to accept the time

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

me "time". Nevertheless, rather than discussing the complicated *source* of UTC, instead, the question I am raising here has to do with how we *communicate* UTC, and in particular, how we communicate the UTC using the POSIX compatible command `date -u`. And for that, it might be most

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

laying UTC that way. And even if I agreed with you, longstanding practice is to for "date -u" to respect the current locale, and POSIX requires this behavior. So there are good reasons for keeping the behavior the way it is. To get the behavior you prefer, you can run "LC_ALL=C

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

00Z is midnight Greenwich time. "Greenwich time" is the time in Greenwich, not the time somewhere else in the world. Since 1968 December, the audio announcements from the WWV broadcasts from Fort Collins Colorado always say "Coordinated Universal Time", in 24 hour format, an

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

On Tue, Aug 19, 2025, at 09:13, James Feeney via GNU coreutils Bug Reports wrote: > > Yes, that's it, along with the coincidence that MDT relative to UTC is > exactly 12 hours. > That coincidence is true only in base 4. :)

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

relative to UTC is exactly 12 hours. Thanks for pointing-out the glaringly obvious in retrospect. Reviewing the `man 1 date` page, and after some trial and error: $ date -uR Tue, 19 Aug 2025 14:35:50 + I did also resort to "time format 24 hours on shell with date command": h

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

tag 79261 notabug close 79261 stop On 17/08/2025 17:02, James Feeney via GNU coreutils Bug Reports wrote: Arch Linux coreutils 9.7-1 $ timedatectl;date;date -u Local time: Sun 2025-08-17 09:50:24 MDT Universal time: Sun 2025-08-17 15:50:24 UTC RTC

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

On Sun, Aug 17, 2025, at 10:02, James Feeney via GNU coreutils Bug Reports wrote: > Arch Linux > coreutils 9.7-1 > > $ timedatectl;date;date -u >Local time: Sun 2025-08-17 09:50:24 MDT >Universal time: Sun 2025-08-17 15:50:24 UTC >

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

Arch Linux coreutils 9.7-1 $ timedatectl;date;date -u Local time: Sun 2025-08-17 09:50:24 MDT Universal time: Sun 2025-08-17 15:50:24 UTC RTC time: Sun 2025-08-17 15:50:24 Time zone: US/Mountain (MDT, -0600) System clock synchronized: yes

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

On 29/07/2025 06:02, Jeffery Palm wrote: I took a look at this bug, and believe I have a patch that will resolve it. $ ../src/date --debug -d '2024-01-01 8:00:00PM -0500' date: parsed date part: (Y-M-D) 2024-01-01 date: parsed time part: 08:00:00pm UTC-05 date: input timezone: parsed

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

I took a look at this bug, and believe I have a patch that will resolve it. $ ../src/date --debug -d '2024-01-01 8:00:00PM -0500' date: parsed date part: (Y-M-D) 2024-01-01 date: parsed time part: 08:00:00pm UTC-05 date: input timezone: parsed date/time string (-05) date: using specifi

bug#79078: date command: Relative dates fail with ISO 8601 time format and no zone

tag 79078 notabug close 79078 stop Notes below... On 23/07/2025 08:56, Geoff Kuenning via GNU coreutils Bug Reports wrote: Tested on coreutils 9.5 (gentoo) and 8.32 (OpenSuSE). There seems to be an interesting interaction in the code that parses relative dates in the --date switch; relative

bug#79078: date command: Relative dates fail with ISO 8601 time format and no zone

Tested on coreutils 9.5 (gentoo) and 8.32 (OpenSuSE). There seems to be an interesting interaction in the code that parses relative dates in the --date switch; relative specifications used with ISO 8601 base dates can give incorrect results. All tests below were run with a time zone of

bug#76316: date: forgot the full day of the month name

16 00:09, Dan Jacobson wrote: PE> Sorry, I don't understand the bug report. Are you asking for a new PE> feature, or are you saying that currently GNU 'date' outputs incorrect PE> strings for %A and/or %B? If the former, what new feature exactly? And >> Yes the former.

bug#76316: date: forgot the full day of the month name

On 2025-02-16 00:09, Dan Jacobson wrote: PE> Sorry, I don't understand the bug report. Are you asking for a new PE> feature, or are you saying that currently GNU 'date' outputs incorrect PE> strings for %A and/or %B? If the former, what new feature exactly? And Yes t

bug#76316: date: forgot the full day of the month name

All I know is in Chinese the months and days are like 一月一日 (1/1) 二月二日 (2/2) and date(1) will allow me to print 一月 but not 一日 二月 but not 二日 probably because date allows two versions for months 1 or January 2 or February but not days, because in English none is needed. But that's not the cas

bug#76316: date: forgot the full day of the month name

$ man date|grep "locale's full" %A locale's full weekday name (e.g., Sunday) %B locale's full month name (e.g., January) $ LC_ALL=zh_TW.UTF-8 date +%A%B 週日二月 OK that's great. But you forgot locale's full day of the month name

bug#76316: date: forgot the full day of the month name

$ man date|grep "locale's full" %A locale's full weekday name (e.g., Sunday) %B locale's full month name (e.g., January) $ LC_ALL=zh_TW.UTF-8 date +%A%B 週日二月 OK that's great. But you forgot locale's full day of the month name

bug#74107: bug#74808: date.1: Some remarks and and a patch for editorial changes for this man page

On 03/02/2025 06:24, Brendan O'Dea wrote: On Fri, Dec 13, 2024 at 02:13:44PM -0700, Glenn Golden wrote: While the patient is on the table, might it be possible to also look into this: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74107 From what Padraig said in his response to the above re

bug#74107: bug#74808: date.1: Some remarks and and a patch for editorial changes for this man page

On Fri, Dec 13, 2024 at 02:13:44PM -0700, Glenn Golden wrote: >While the patient is on the table, might it be possible to also look into >this: > >https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74107 > >From what Padraig said in his response to the above report, it sounded like >fixing it on

bug#74808: date.1: Some remarks and and a patch for editorial changes for this man page

On Fri, Dec 13, 2024 at 01:32:50PM -0700, Paul Eggert wrote: >I was thinking of something simpler, like this: > >.if t .if \n(.g \{\ >. ds fC \f(CR >. ds fP \fP >.\} Looks like a good option, I've done something along these lines for the next release: https://salsa.debian.org/bod/help2man/-/com

bug#75208: Please mention "date %D considered harmful" in manpage

Thanks for the suggestion. I installed the attached. Although it doesn't go quite as far as your suggestion, it should adequately warn people who pay attention to warnings.From a0c3e5648be9727d1e2e18f18f143c619f825706 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 30 Dec 2024 11:

bug#75208: Please mention "date %D considered harmful" in manpage

America is the only country to use %m/%d/%y. Since American programmers seem to assume its a good format to use in their scripts (after all, the manpage states: "%D: date"), it would be a good idea if the man/infopage came with a big fat warning like: "%D is considered harmful

bug#74107: bug#74808: date.1: Some remarks and and a patch for editorial changes for this man page

On Fri, Dec 13, 2024, at 00:38, Brendan O'Dea wrote: > > bug-help2man is is an alias to my email address, and I have fallen behind. > I finally got to working through the backlog yesterday (mostly prompted by > an email about this issue), but ran out of time. I'll push a release when > I return. >

bug#74808: date.1: Some remarks and and a patch for editorial changes for this man page

I was thinking of something simpler, like this: .if t .if \n(.g \{\ . ds fC \f(CR . ds fP \fP .\} and then surrounding constant-width text with \*(fC and \*(fP. This should be legible with older troff without worrying whether the older troff supports CW. For older troff, being legible is goo

bug#74808: date.1: Some remarks and and a patch for editorial changes for this man page

Use the string 'mC', defined in groff's an-ext.tmac file .\" register .g is defined to be 1 for heirloom-doc (and groff) .if t \{\ . ie \n(.g \{\ .ds mC CR .\" tm constant width font used is \*(mC .\" String mC is \*(mC . \} . el \{\ .if !'\*(mC'' \{\ . tm String "mC" alrea

bug#74808: date.1: Some remarks and and a patch for editorial changes for this man page

On Fri, 13 Dec 2024, 17:47 Paul Eggert, wrote: > On 12/12/24 12:32, Brendan O'Dea wrote: > > From that it seems that CR is a replacement which should work for > groff, if > > I read that correctly, James Clarke used that from the start. > > Perhaps help2man could be changed to generate man pages

bug#74808: date.1: Some remarks and and a patch for editorial changes for this man page

On 12/12/24 12:32, Brendan O'Dea wrote: From that it seems that CR is a replacement which should work for groff, if I read that correctly, James Clarke used that from the start. Perhaps help2man could be changed to generate man pages that use CR if it's groff, and CW otherwise. I haven't se

bug#74808: date.1: Some remarks and and a patch for editorial changes for this man page

ryone, given the prevalence of groff. I could provide an option with CR as the default, but that wouldn't really help anyone who received the pre-built date.1 . On Thu, 12 Dec 2024, 15:07 Paul Eggert, wrote: > On 2024-12-11 18:28, Bjarni Ingi Gislason wrote: > > troff::236:

bug#74808: date.1: Some remarks and and a patch for editorial changes for this man page

On 2024-12-11 18:28, Bjarni Ingi Gislason wrote: troff::236: warning: font name 'CW' is deprecated That "CW" was generated by help2man so I'll CC this message to as per . Can you suggest what help2man should use instead of \f(CW? Help2man ne

bug#74808: date.1: Some remarks and and a patch for editorial changes for this man page

depends on: ii libacl1 2.3.2-2+b1 ii libattr1 1:2.5.2-2 ii libc62.40-4 ii libgmp10 2:6.3.0+dfsg-3 ii libselinux1 3.7-3+b1 ii libssl3t64 3.3.2-2 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information Input file is date.1 Any

bug#73510: Questions on date command.

On 27/09/2024 08:18, Benjamin Vargin via GNU coreutils Bug Reports wrote: Hello, First of all, I would like to thank you for all the works accomplished by your teams !! I'm currently implementing functions in bash which are using the command "date". I have noticed something

bug#73510: Questions on date command.

Hello, First of all, I would like to thank you for all the works accomplished by your teams !! I'm currently implementing functions in bash which are using the command "date". I have noticed something strange when I realize manipulation during the daylight saving from Winter to

bug#72023: feature request for date(1): strptime-style format

I agree strptime()-style input format specification is badly missing in GNU date. Most other implementations support it: - BSD with -f since 1997 (on FreeBSD at least; see also -v for adjustments) - ast-open's with -p since 2004 (also via standard getdate() DATEMSK) - busybox' with -D

bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess

Fair enough... I was worried you were objecting to the whole concept, not just that one function -Original Message- From: Paul Eggert Sent: Wednesday, July 10, 2024 12:23 PM To: Yagnatinsky, Mark : IT (NYK) ; 72...@debbugs.gnu.org Subject: Re: bug#72023: feature request for date(1

bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess

On 7/10/24 15:12, mark.yagnatin...@barclays.com wrote: Re: strptime is mistake: you think that particular function is bad Yes, though I lack the time to go into details right now.

bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess

NYK) ; 72...@debbugs.gnu.org Subject: Re: bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess CAUTION: This email originated from outside our organisation - egg...@cs.ucla.edu Do not click on links, open attachments, or respond unless yo

bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess

On 7/10/24 13:59, mark.yagnatinsky--- via GNU coreutils Bug Reports wrote: BSD date has this flag Unfortunately it uses -f for the flag, and -f already has a well-established different meaning in GNU 'date'. We could add it to GNU date under a different (long) option name, though

bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess

Re: other dates: BSD date has this flag, and needs it, because it mostly refuses to guess. Re: strptime... I didn't mean it has to literally be that function. I just want some way to say what format the input is in. -Original Message- From: Paul Eggert Sent: Wednesday, July 10, 2

bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess

I'm dubious. I've never had much luck with strptime, as in practice it has its own glitches that are even worse than what 'date' currently uses. For example, it's dicey in non-C locales, and it mishandles time zones and daylight saving transitions even in the C loca

bug#72023: feature request for date(1): strptime-style format string when you don't want date to guess

I suspect this has been requested many times over the decades but I haven't found anything in the issue tracker so... The date command lets you choose my output format, but for input it tries to figure it out without hints. For interactive use, this is great. For usage in scripts, this is

bug#71986: RFC: date @ to support ms.

On 7/9/24 03:19, Richard Neill wrote: IP_JSON=$(curl https://whatsmyip.dev/api/ip) TS=$(echo $IP_JSON | jq '.ts' -r) TS=$(echo "$TS/1000" | bc) DATE=$(date --date @$TS) This is better, as it saves on subprocesses: IP_JSON=$(curl https://whatsmyip.dev/api/ip) TS=$(jq -nr

bug#71986: RFC: date @ to support ms.

. For occasional use one can just use the shell, with no new option needed. For your example: $ ms=1720378861258 $ date -d@${ms%???} Sun Jul  7 21:01:01 CEST 2024 But really, it's better to use a decimal point, as Andreas suggested. Simple, clear, unambiguous, and no new option n

bug#71986: RFC: date @ to support ms.

new option needed. For your example: $ ms=1720378861258 $ date -d@${ms%???} Sun Jul 7 21:01:01 CEST 2024 But really, it's better to use a decimal point, as Andreas suggested. Simple, clear, unambiguous, and no new option needed regardless of whether the timestamps have ms or μs

bug#71986: RFC: date @ to support ms.

On 08/07/2024 17:33, Andreas Schwab wrote: date --date='@1720378861.258' --rfc-3339=ns Thanks. The problem is that the input string (from elsewhere) is "1720378861258" i.e. it's "integer ms", not "seconds with a decimal". Also, this is an

bug#71986: RFC: date @ to support ms.

On Jul 07 2024, Richard Neill wrote: > I've noticed a lot of systems now return the timestamp in milliseconds > since the epoch, rather than seconds. This means that e.g. > > date --date='@1720378861258' > > will do something rather unexpected! > > May

bug#71986: RFC: date @ to support ms.

Hello Pádraig, On 08/07/2024 12:33, Pádraig Brady wrote: On 07/07/2024 20:46, Richard Neill wrote: Hello, I've noticed a lot of systems now return the timestamp in milliseconds since the epoch, rather than seconds. This means that e.g.     date --date='@1720378861258' wi

bug#71986: RFC: date @ to support ms.

On 07/07/2024 20:46, Richard Neill wrote: Hello, I've noticed a lot of systems now return the timestamp in milliseconds since the epoch, rather than seconds. This means that e.g. date --date='@1720378861258' will do something rather unexpected! May I suggest that it would

bug#71986: RFC: date @ to support ms.

Hello, I've noticed a lot of systems now return the timestamp in milliseconds since the epoch, rather than seconds. This means that e.g. date --date='@1720378861258' will do something rather unexpected! May I suggest that it would be nice if date had an input format tha

bug#68064: Date addition error with “day Monthname” versus “Monthname day”

tag 68064 notabug close 68064 stop On 27/12/2023 17:29, Larry Ploetz wrote: It seems like there might be a problem with date addition when the base date is specified as “day Monthname” instead of “Monthname day”, where the offset is being interpreted as an absolute year value. This may be

bug#68064: Date addition error with “day Monthname” versus “Monthname day”

It seems like there might be a problem with date addition when the base date is specified as “day Monthname” instead of “Monthname day”, where the offset is being interpreted as an absolute year value. This may be locale-specific. :bin larry$ locale LANG="en_US.UTF-8"

bug#63784: date --date "1 month ago" +%Y-%m does not work as expected on day 31

On 29/05/2023 12:55, Jelle de Jong wrote: Hello everybody, I been hitting an issue for a while now that date commands return the wrong month on day 31 of a month and my automations stops working on correctly on these days. root@sydney:~# date Wed Aug 31 22:09:04 CEST 2022 root@sydney:~# date

bug#63784: date --date "1 month ago" +%Y-%m does not work as expected on day 31

Hello everybody, I been hitting an issue for a while now that date commands return the wrong month on day 31 of a month and my automations stops working on correctly on these days. root@sydney:~# date Wed Aug 31 22:09:04 CEST 2022 root@sydney:~# date --date "1 month ago" +%Y-%m 20

bug#63349: Bug in date when using UTC/GMT timeszones in the TZ variable

On 7.5.2023 14:52, Andreas Schwab wrote: On Mai 07 2023, Eiríkur Hjartarson via GNU coreutils Bug Reports wrote: Now the "bug": It's not a bug. Thanks for the explanation, in my defense, I did read the date info page and the FAQ at https://www.gnu.org/software/coreutil

bug#63349: Bug in date when using UTC/GMT timeszones in the TZ variable

On 5/7/23 07:52, Andreas Schwab wrote: Thus TZ=UTC+2 means two hours before UTC. Yes, and this mistake seems to be common enough that I installed the attached patch into Gnulib, so that it'll propagate into the Coreutils manual, which should help people who read the 'date'

bug#63349: Bug in date when using UTC/GMT timeszones in the TZ variable

On Mai 07 2023, Eiríkur Hjartarson via GNU coreutils Bug Reports wrote: > Now the "bug": It's not a bug. > $ TZ=Europe/Riga date --iso-8601=minutes -d "2024-01-01T00:00-05:00" > 2024-01-01T07:00+02:00 > > $ TZ=UTC+2 date --iso-8601=minutes -d "202

bug#63349: Bug in date when using UTC/GMT timeszones in the TZ variable

Hi, I'm on Fedora-38 GNU/Linux and the version string of 'date' is "date (GNU coreutils) 9.1". $ ls -l /etc/localtime lrwxrwxrwx. 1 root root 40 jan 11 2022 /etc/localtime -> ../usr/share/zoneinfo/Atlantic/Reykjavik Now the "bug": $ TZ=Europe/Ri

bug#63119: date -Ins has a comma!!

On 4/27/23 07:53, aaa jjj wrote: What does ISO 8601 say about this? I believe ISO 8601-1:2019/Amd 1:2022 prefers a comma, though a period is allowed. Unfortunately I can't easily check this because the standards are not published online and you need to pay to read them. Isn't ISO wonderful?

bug#63119: date -Ins has a comma!!

Hi, is it not a bug, that if I do LC_ALL=C date -u -Ins gives me this: 2023-04-27T13:30:15,976772648+00:00 I'm talking about the comma. What is it doing there??? Should this not be a dot instead? Here's the code: https://github.com/coreutils/core

bug#62497: maybe date -f should generate an error

dircolors. cheers, Pádraig From a9bd274616a8d2e99736b498e657cda4e6954f3f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Tue, 28 Mar 2023 14:24:29 +0100 Subject: [PATCH] dircolors: diagnose read errors * NEWS: Mention the fix. * src/dircolors.c: Fail upon read error fr

bug#62497: maybe date -f should generate an error

?P=C3=A1draig=20Brady?= Date: Tue, 28 Mar 2023 13:38:52 +0100 Subject: [PATCH] tests: add a test case for the previous date fix * NEWS: Also mention this bug fix. * tests/misc/date-f.sh: Add a new test. * tests/local.mk: Reference the new test. --- NEWS | 4 tests/local.mk

bug#62497: maybe date -f should generate an error

Thanks for reporting that. I installed the attached to fix it.From 9c5e542fd190a14431092e3b6cb45d18fe95f26f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 28 Mar 2023 01:52:43 -0700 Subject: [PATCH] date: diagnose -f read errors * src/date.c (batch_convert): Diagnose read errors, fixing

bug#62497: maybe date -f should generate an error

Hello The usual case is: $ echo "2023-03-27 08:30:00" > dates.txt $ echo "2023-04-01 12:00:00" >> dates.txt $ /usr/bin/date -f dates.txt Mon Mar 27 08:30:00 CEST 2023 Sat Apr 1 12:00:00 CEST 2023 If done on a non existing file, we get: $ date -f non-existing /u

bug#62405: date update

On 3/23/23 06:18, Edgar Aquino Rodriguez wrote: if i run date (system time) Thu Mar 23 07:15:39 MST 2023 i dont now but if i run date --custom Thu Mar 23 13:34:15 MST 2023 or how can get multiple timezones in the same system Although it's not clear what you're asking for, but per

bug#62405: date update

i had a question about date time on linux terminal, if is possible had multiple times i mean something like this if i run date (system time) Thu Mar 23 07:15:39 MST 2023 i dont now but if i run date --custom Thu Mar 23 13:34:15 MST 2023 or how can get multiple timezones in the same system

bug#61537: [Bug-coreutils] 'cp -au' re-copies (removes and relinks) hard links that are up to date

es and relinks) hard links that are up to date and it didn't recopy with 8.11. I have tried coreutils 8.23 and 9.1, but I think all versions after 8.11 have this problem. To illustrate the problem, I first create a directory 'src' containing two linked files and then make a copy

bug#61528: date doesn't parse negative years

Hello, I noticed that date doesn't accept negative years, such as in the date: -0001-01-02 (i.e. 2nd Jan 2 BC). It's also somewhat puzzling that even through date will convert a timestamp in that year to an output string, it won't parse that string as valid (i.e. the las

bug#60030: Small error in date command

tag 60030 notabug close 60030 stop On 13/12/2022 02:50, Malin Freeborn wrote: Hi bug-team, There's a small error in the date man page. If you search for `%F` you'll notice the date is summarized as so: %F full date; like %+4Y-%m-%d The example shows the `%` sign before the `

bug#60030: Small error in date command

Hi bug-team, There's a small error in the date man page. If you search for `%F` you'll notice the date is summarized as so: %F full date; like %+4Y-%m-%d The example shows the `%` sign before the `+`. Best, - Malin

bug#59827: [PATCH] info date to be explicit about the date formats

Thanks for the suggestion. I installed the attached which isn't exactly what you sent but which implements the basic idea.From 5399f2aac4dc8dd4392a1194dc9bdbb2bcc6272c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 5 Dec 2022 18:42:19 -0800 Subject: [PATCH] doc: improve date -

bug#59827: [PATCH] info date to be explicit about the date formats

hello coreutils maintainers, I would like info page of the date to be explicit about the ready to use date formats so users can pick them as example for their own ones (as example: just remove the timezone information). regards, marc --- doc/coreutils.texi | 5 + 1 file changed, 5

bug#58599: `date -d $(date)` error for non en_* locale

On 10/17/22 07:44, Ruslan Kovtun wrote: According to "do one thing and do it well" and to the fact of '-d/--date' option existence, `date` should be able to parse its default output in any locale. Patches would be welcome. Good luck getting it to work, though. Many date f

bug#58599: `date -d $(date)` error for non en_* locale

$ date -d "$( date )" date: invalid date ‘Пн 17 окт 2022 17:34:00 EEST’ $ date -d "Mon 17 oct 2022 17:34:00 EEST" Пн 17 окт 2022 17:34:00 EEST According to "do one thing and do it well" and to the fact of '-d/--date' option existence, `date` should be

bug#58494: touch resists date 2022-09-11T00:00:00

> > In Santiago, Chile, that timestamp does not exist. Is your timezone set > > to Santiago time? That would explain your symptoms. > > I am, but I don't understand why the timezone would make a time not to > exist... What am I missing? Uh, oh, it's daylight saving time change... never thought of

bug#58494: touch resists date 2022-09-11T00:00:00

On Thu Oct 13, 2022 at 2:42 PM -03, Paul Eggert wrote: > On 2022-10-12 18:58, Felix Freeman via GNU coreutils Bug Reports wrote: > > $ touch -t 20220911 algo > > touch: invalid date format ‘20220911’ > > $ touch -d 2022-09-11T00:00:00 algo > >

bug#58494: touch resists date 2022-09-11T00:00:00

On 2022-10-12 18:58, Felix Freeman via GNU coreutils Bug Reports wrote: $ touch -t 20220911 algo touch: invalid date format ‘20220911’ $ touch -d 2022-09-11T00:00:00 algo touch: invalid date format ‘2022-09-11T00:00:00’ In Santiago, Chile, that timestamp does not

bug#58494: touch resists date 2022-09-11T00:00:00

I think I found a bug. In any format that I try to touch a file with the date 2022-09-11 at 00:00, touch says I'm entering an invalid date format. $ touch -t 20220911 algo touch: invalid date format ‘20220911’ $ touch -d 2022-09-11T00:00:00 algo touch: invalid date f

bug#57834: Date Command Anomaly

On 23/09/2022 14:03, Bert Wesarg via GNU coreutils Bug Reports wrote: Dear, $ TZ=Europe/London date --debug --date="2022/03/27 01:00:00" date: warning: value 2022 has 4 digits. Assuming YYYY/MM/DD date: parsed date part: (Y-M-D) 2022-03-27 date: parsed time part: 01:00:00 d

bug#57834: Date Command Anomaly

Dear, $ TZ=Europe/London date --debug --date="2022/03/27 01:00:00" date: warning: value 2022 has 4 digits. Assuming YYYY/MM/DD date: parsed date part: (Y-M-D) 2022-03-27 date: parsed time part: 01:00:00 date: input timezone: TZ="Europe/London" environment value date: usi

bug#57834: Date Command Anomaly - Forget it. My Oversite

Sorry, my oversite, It was the transition from Greenwich Mean Time to British Summer time 27th March. Martin Hughes

bug#57834: Date Command Anomaly

Dear Sir, I have stumbled across this anomaly whilst processing a series of dates. I have not found any other legal date combination that generates this error. Perl time facilities seem to be affected by this too. mjh@carnaby:~> date --date="2022/03/27 00:00:00" Sun 27 Mar 00:0

bug#55401: date man page

On 14/05/2022 01:42, Pádraig Brady wrote: On 13/05/2022 20:10, t0th wrote: Man page of date command should make explicit that -d and -r options are mutually exclusive. Right. More accurately, we might have a sentence to say that: "All options to specify the date to display are mut

bug#55401: date man page

On 13/05/2022 20:10, t0th wrote: Man page of date command should make explicit that -d and -r options are mutually exclusive. Right. More accurately, we might have a sentence to say that: "All options to specify the date to display are mutually exclusive. I.e.: --date, --file, --refe

bug#55401: date man page

Man page of date command should make explicit that -d and -r options are mutually exclusive. date -d -3 minutes -r tmp.txt "+%Y%m%d_%H%M" date: the options to specify dates for printing are mutually exclusive

bug#55183: date

does define it, you can see: $ LC_TIME=C date +%r 05:00:50 PM $ LC_TIME=zh_CN.utf8 date +%r 下午 05时00分50秒 You can look up these values with: $ LC_TIME=C locale t_fmt_ampm t_fmt am_pm %I:%M:%S %p %H:%M:%S AM;PM Note "t_fmt_ampm" if defined, takes precedence over "t_fm

bug#55183: date

%r has a space at the end that makes me insanely angry fix it

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

Am 15.04.2022 00:10, schrieb Paul Eggert: On 4/1hour...4/22 09:48, joerg.boeh...@snafu.de wrote: %N nanoseconds (0..9) The current description gives the impression that nanoseconds are an integral quantity like seconds and minutes. This leads the user to assume that leadi

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

On 4/14/22 09:48, joerg.boeh...@snafu.de wrote: %N nanoseconds (0..9) The current description gives the impression that nanoseconds are an integral quantity like seconds and minutes. This leads the user to assume that leading zeros are being removed. Similar wording is u

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

%-N is intended to be used after a decimal point... Please note this intention in the man-page. The current man-page: %N nanoseconds (0..9) The current description gives the impression that nanoseconds are an integral quantity like seconds and minutes. This leads the user

bug#54916: 4 invalid dates reported by "date"

On 4/13/22 06:30, Martins Ozolins via GNU coreutils Bug Reports wrote: ozoma@ozoma-ThinkPad-X250:$ date +%s --date="1981-04-01" date: invalid date ‘1981-04-01’ This is because your invocation is equivalent to: date +%s --date="1981-04-01 00:00:00" and there was

bug#54916: 4 invalid dates reported by "date"

Hello software maintainers. While using a script that relies upon the "date" utility to reconstruct historical calendar dates, I came across errors when submitting only the first day of the month April for the years 1981, 1982, 1982 and 1984. I assume no April fools is int

bug#48085: date -d greater than 23 years ago gives error invalid date

ep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 19 Feb 2022 15:04:43 -0800 Subject: [PATCH] mktime: improve heuristic for ca-1986 Indiana DST Problem reported by Mark Krenz <https://bugs.gnu.org/48085>. * lib/mktime.c (__mktime_internal): Be more generous about accepting arguments with the

bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"

On 2/14/22 01:41, Stéphane Archer wrote: is +'%Y-%m-%dT%H:%M:%S.0Z' do what I want To format an arbitrary timestamp you want "+%Y-%m-%dT%H:%M:%S.%1NZ", unless you always want a zero after the period. Closing the bug report as there's no bug here.

bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"

re? Thank you again and sorry for the bug report, it was late and I was sure to have found a bug ^^" Best regards Stéphane Archer On Mon, Feb 14, 2022 at 9:17 AM Andreas Schwab wrote: > On Feb 13 2022, Stéphane Archer wrote: > > > $ date -d "17 april 2022 + 36 week 5pm&quo

bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"

On Feb 13 2022, Stéphane Archer wrote: > $ date -d "17 april 2022 + 36 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' > 2022-12-25T17:00:00.0Z > $ date -d "17 april 2022 + 37 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' > 2022-01-01T17:00:00.0Z > $ date -d "17

bug#53982: date (GNU coreutils) 8.30 bug report "17 april 2022 + 37 week 5pm"

Hi, I hope this is the right place to do my bug report. please see the following shell input-output: ``` $ date -d "17 april 2022 + 36 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' 2022-12-25T17:00:00.0Z $ date -d "17 april 2022 + 37 week 5pm" +'%G-%m-%dT%H:%M:%S.0Z' 20

bug#50115: date command arithmetic involving the epoch produces "invalid date"

Thanks for the bug report. I installed the attached patches to Gnulib and to Coreutils, and the fix should be in the next Coreutils release.From aa0d1e7800903f2d75432d78aa64a0e9770e83f2 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 5 Feb 2022 11:05:44 -0800 Subject: [PATCH] parse

  1   2   3   4   5   6   7   8   9   10   >