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.

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

Indeed, it was a bug in glibc locale data [1] and has been fixed [2] in version 2.17. If you mention Fedora the fix has been included in Fedora 19. Please close this bug report, it was not a coreutils issue and it has been fixed 5.5 years ago. Regards, Rafal [1]

bug#30795: Issue with date command and EDT

; wrote: Please see the issue below: 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 "old date 4 days ago

bug#19856: Bad month translation printed with date command in Greek locale

as done, since this is all that should be needed as far as coreutils itself is concerned. >From db94330dd65b246f4fb96e017f1425fe0c1246a8 Mon Sep 17 00:00:00 2001 From: Paul Eggert <egg...@cs.ucla.edu> Date: Tue, 6 Mar 2018 15:15:24 -0800 Subject: [PATCH] build: update gnulib submodule

bug#26101: Counterproductive calculation order in date

Hello Vincent and all, On 2018-02-06 05:37 PM, Vincent Lefevre wrote: Similarly: zira% date +%Y-%m-%d -d '2003-02-01 - 1 month' 2003-01-01 zira% date +%Y-%m-%d -d '2003-02-01 - 31 days' 2003-01-01 but if I add "+ 1 month", I get different results: zira% date +%Y-%m-%d -d '2003-

bug#26101: Counterproductive calculation order in date

On 2017-03-15 13:23:48 +0100, Ulf Zibis wrote: > A more simple example without touch: > $ date +%F > 2017-03-15 > $ date -d "-20 day" +%F > 2017-02-23 > $ date -d "-20 day -2 month" +%F > 2016-12-26 > $ date -d "-2 month -20 day" +%F > 201

bug#30102: date -d 'next tuesday, 2 years ago' # Is something like that supported?

Hi Assaf: On Sun 1/14/18 3:50 -0700 Assaf Gordon wrote: > On 2018-01-13 05:03 PM, bug-coreut...@trodman.com wrote: > In version 8.27 the date command has an additional option called > "--debug" which can help in understanding the date parsing. Thanks/good to know. > I wil

bug#30102: date -d 'next tuesday, 2 years ago' # Is something like that supported?

tag 30102 notabug close 30102 stop Hello, On 2018-01-13 05:03 PM, bug-coreut...@trodman.com wrote: $ date --version date (GNU coreutils) 8.27 In version 8.27 the date command has an additional option called "--debug" which can help in understanding the date parsing.

bug#30102: date -d 'next tuesday, 2 years ago' # Is something like that supported?

$ date --version date (GNU coreutils) 8.27 --snip $ info date -n 'Date input formats' |grep 'next tue' * Relative items in date strings:: next tuesday, 2 years ago. My goal is to find for example the date of the first Saturday after 1/7/2018 with a single date command. -- thanks!

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

Thanks for the quick reply. Will use your suggestions. Noam From: Bishop Bettini [mailto:bishop.bett...@gmail.com] Sent: Wednesday, December 6, 2017 6:49 PM To: Noam Arad <noam.a...@kaltura.com> Cc: 29...@debbugs.gnu.org Subject: Re: bug#29589: date %k adds extra space for single digits

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

On Wed, Dec 6, 2017 at 4:17 AM, Noam Arad <noam.a...@kaltura.com> 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/%d %k:%M:%S" when run at "2017/12/06 9:16:26" will >

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

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/%d %k:%M:%S" when run at "2017/12/06 9:16:26" will give the output "2017/12/06 9:16:26" NOTE: there are two spaces between "06" and "9". Thanks

bug#29377: date/time of "ls -lh" translation is wrong for Simplified Chinese

com>: > How about we remove all space characters in date/time? > > I mean to display date/time like "11月21日 11:22" or "11月21日11:22". > > On Fri, Nov 24, 2017 at 3:31 PM, Yasuaki Taniguchi/谷口康明 <yasua...@gmail.com> > wrote: >> >> Hello. >>

bug#29377: date/time of "ls -lh" translation is wrong for Simplified Chinese

How about we remove all space characters in date/time? I mean to display date/time like "11月21日 11:22" or "11月21日11:22". On Fri, Nov 24, 2017 at 3:31 PM, Yasuaki Taniguchi/谷口康明 <yasua...@gmail.com> wrote: > Hello. > > As for Japanese, I want to ap

bug#29377: date/time of "ls -lh" translation is wrong for Simplified Chinese

translated Japanese messages is "`11月 21 11:22", the number of columns is 13 (月 is full-width character and it spends 2 columns). If we append 日 after the number of the day, the number of columns will be 15. That is too long. Displaying date and time is very complex issue. 2017-11-24 1

bug#29377: date/time of "ls -lh" translation is wrong for Simplified Chinese

Thanks, I see. On Tue, Nov 21, 2017 at 6:06 PM, Eric Blake <ebl...@redhat.com> wrote: > tag 29377 notabug > thanks > > On 11/20/2017 11:55 PM, Peng Wu wrote: > > Hi, > > > > Currently the output of "ls -lh" for Simplified Chinese misses the "

bug#29377: date/time of "ls -lh" translation is wrong for Simplified Chinese

tag 29377 notabug thanks On 11/20/2017 11:55 PM, Peng Wu wrote: > Hi, > > Currently the output of "ls -lh" for Simplified Chinese misses the "日" > character for the date. > > It displays date as "11月 21", but in Simplified Chinese it should

bug#29377: date/time of "ls -lh" translation is wrong for Simplified Chinese

Hi, Currently the output of "ls -lh" for Simplified Chinese misses the "日" character for the date. It displays date as "11月 21", but in Simplified Chinese it should display "11月 21日". Maybe it also happens with Traditional Chinese and Japanese. After c

bug#27482: date: minus and ago in same sentence

de up of other components...) 3. Because it will avoid the user getting these surprising results, $ date -d 'two weeks ago' date: invalid date ‘two weeks ago’ $ date -d 'now - two weeks ago' date: invalid date ‘now - two weeks ago’ $ date -d 'now - 2 weeks ago' Sun Jul 9 18:39:23 CST 2017 Or just catc

bug#26293: GNU date program

tags 26293 notabug close 26293 stop Hello, > On Mar 28, 2017, at 22:26, Dean Gibson AE7Q <wa7dem.st...@ae7q.com> wrote: > > Consider: "date -d '2017-03-28 17:12:34 + 3 hours'" Due to the way date strings are parsed, the "+3" part is used as the input time

bug#26293: GNU date program

Consider: "date -d '2017-03-28 17:12:34 + 3 hours'" In "date (coreutils) 5.2.1 (March 2004)" it gives "Tue Mar 28 20:12:34 PDT 2017". In "GNU coreutils 8.22 February 2016)" it gives "Tue Mar 28 08:12:34 PDT 2017". Both servers use /etc/loc

bug#26101: Counterproductive calculation order in date

Am 15.03.2017 um 16:53 schrieb Pádraig Brady: "coreutils FAQ" By the way, I think there is a typo: $ date --date="$(date +%Y-%m-15) -1 month" +'Last month was %B.' Last month was June. $ date --date="$(date +%Y-%m-15) +1 month" +'Next month will be %B.' Nex

bug#26101: Counterproductive calculation order in date

Am 15.03.2017 um 15:46 schrieb Eric Blake: List policy is to reply-to-all, so that we don't have to think about who is subscribed, while making sure that even unsubscribed readers stay in the loop on the message they are interested in. The list server has settings where you can request that

bug#26101: Counterproductive calculation order in date

Am 15.03.2017 um 15:40 schrieb Assaf Gordon: To give more details about the inter working of date adjustments: Much thanks for outlining these details in great clarity. You'd like to be able to do date calculations in some predictable way, Yes! Currently the result is not predictable

bug#26101: Counterproductive calculation order in date

Correcting my own mistake: > On Mar 15, 2017, at 10:40, Assaf Gordon wrote: > > When adjusting days, it is equivalent to subtracting > the number of seconds from the current unix epoch (i.e. seconds since > 1970-01-01). > [...] Adjusting days is equivalent to adjusting

bug#26101: Counterproductive calculation order in date

it's covered in "coreutils FAQ", > though it might deserve a discussion there. If mentioning date adjustment in the 'gotcha' page, perhaps the following examples will be useful (short but sufficient to illustrate the problems). All examples work in EDT timezone (= "America

bug#26101: Counterproductive calculation order in date

On 15/03/17 05:44, Eric Blake wrote: > On 03/15/2017 07:23 AM, Ulf Zibis wrote: > >> >> A more simple example without touch: >> $ date +%F >> 2017-03-15 >> $ date -d "-20 day" +%F >> 2017-02-23 >> $ date -d "-20 day -2 month"

bug#26101: Counterproductive calculation order in date

On 03/15/2017 08:43 AM, Ulf Zibis wrote: > > Am 15.03.2017 um 13:44 schrieb Eric Blake: >> Maybe you are confused on how date implements "subtract a month". It >> does NOT do "subtract 28, 29, 30, or 31 days as appropriate", but rather >> does "su

bug#26101: Counterproductive calculation order in date

> On Mar 15, 2017, at 09:43, Ulf Zibis <ulf.zi...@gmx.de> wrote: > > Am 15.03.2017 um 13:44 schrieb Eric Blake: >> Maybe you are confused on how date implements "subtract a month". It >> does NOT do "subtract 28, 29, 30, or 31 days as appropriate",

bug#26101: Counterproductive calculation order in date

Am 15.03.2017 um 13:44 schrieb Eric Blake: Maybe you are confused on how date implements "subtract a month". It does NOT do "subtract 28, 29, 30, or 31 days as appropriate", but rather does "subtract 30 days, for lack of anything better to do". Are you really su

bug#26101: Counterproductive calculation order in date

On 03/15/2017 07:23 AM, Ulf Zibis wrote: > > A more simple example without touch: > $ date +%F > 2017-03-15 > $ date -d "-20 day" +%F > 2017-02-23 > $ date -d "-20 day -2 month" +%F > 2016-12-26 > $ date -d "-2 month -20 day" +%F > 201

bug#26101: Counterproductive calculation order in date

Eric, much thanks for your detailed examination. Am 15.03.2017 um 02:21 schrieb Eric Blake: Let's try this with the new --debug option of 8.26 Great, but current version of my Ubuntu is 8.25 $ date --debug -d "$(($(date -r ChangeLog +%s)-$(date +%s))) seconds -2 months" da

bug#26101: Counterproductive calculation order in date

On 03/14/2017 07:17 PM, Ulf Zibis wrote: > Hi, > > with > $ date -r test > I get: > Di 10. Jan 22:39:14 CET 2017 > but with > $ date -d "$(($(date -r test +%s)-$(date +%s))) seconds -2 months" > I get: >Sa 12. Nov 22:39:14 CET 2016 Le

bug#26101: Counterproductive calculation order in date

Hi, with $ date -r test I get: Di 10. Jan 22:39:14 CET 2017 but with $ date -d "$(($(date -r test +%s)-$(date +%s))) seconds -2 months" I get: Sa 12. Nov 22:39:14 CET 2016 I think the better result would be according to a calculation order from left to right: Sa

bug#26081: --date=STRING error that started midnight 3/12

Thank you yes, the debug option is going to be very useful. Fevzi On 3/13/17 9:06 PM, Pádraig Brady wrote: On 13/03/17 05:17, Eric Blake wrote: tag 26081 notabug thanks On 03/13/2017 12:09 AM, Fevzi Karavelioglu wrote: Hello, I started getting an error with the following command: $> d

bug#26081: closed (Re: bug#26081: --date=STRING error that started midnight 3/12)

happen too soon for me!). I will need to add special logic to my code to handle this. It is going to be fun. Fevzi On 3/13/17 5:18 AM, GNU bug Tracking System wrote: Your bug report #26081: --date=STRING error that started midnight 3/12 which was filed against the coreutils package, has been

bug#26081: --date=STRING error that started midnight 3/12

On 13/03/17 05:17, Eric Blake wrote: > tag 26081 notabug > thanks > > On 03/13/2017 12:09 AM, Fevzi Karavelioglu wrote: >> Hello, I started getting an error with the following command: >> >> $> date --date="02:05 tomorrow" +%s >> *date: invalid d

bug#26081: --date=STRING error that started midnight 3/12

tag 26081 notabug thanks On 03/13/2017 12:09 AM, Fevzi Karavelioglu wrote: > Hello, I started getting an error with the following command: > > $> date --date="02:05 tomorrow" +%s > *date: invalid date `02:05 tomorrow'* > > It appears any time 2 in the morning c

bug#26081: --date=STRING error that started midnight 3/12

Hello, I started getting an error with the following command: $> date --date="02:05 tomorrow" +%s *date: invalid date `02:05 tomorrow'* It appears any time 2 in the morning causes the error. But everything else appears to work fine. This appears to have started after midnight on

bug#25560: Alphabetic Character Following date -d

On 01/28/2017 12:15 AM, Owen Leibman wrote: > Testing a script to see how it handled invalid data, I had it execute the > command: > date -d "x023-04-05 01:00" > Somewhat surprisingly, this was not treated as an error. The response was: > Tue Apr 4 06:07:02 LM

bug#25560: Alphabetic Character Following date -d

Owen Leibman wrote: Is the date command behaving as it should for all these examples? Those letters are military time zone abbreviations, so yes.

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

On 27/01/17 07:19, Rami Lehti wrote: > Hi, > > Currently 'date -Iweeks' does not display the ISO 8601 standard's week > format. Neither does it support the ordinal format in that standard. > Attached to this message you will find a patch for this issue. The patch > has been m

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

Hi, Currently 'date -Iweeks' does not display the ISO 8601 standard's week format. Neither does it support the ordinal format in that standard. Attached to this message you will find a patch for this issue. The patch has been made against latest git master branch. The patch itself is trivial

bug#23035: date: regression in timezone printing (+%Z)

The parse_datetime2() API is very new and probably only used by coreutils, so there should be no other fallout from improving the API. I've pushed this NEWS item for the fix. + date again converts from a specified time zone. Previously output was + not converted to the local time zone, and remai

bug#23035: date: regression in timezone printing (+%Z)

edu> Date: Fri, 20 Jan 2017 18:08:03 -0800 Subject: [PATCH 1/2] build: update gnulib submodule to latest --- gnulib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gnulib b/gnulib index 0e68c6a..4e6e16b 16 --- a/gnulib +++ b/gnulib @@ -1 +1 @@ -Subproject

bug#25448: RFC 3339 misdescribed in doc of date(1)

Your bug report raised two points: the numeric time zone -00, and separating date from time with space instead of "T". For -00, you're right that the documentation is messed up. While we're on the topic, 'date' should output the numeric time zone '-00' when the time zone is ind

bug#25448: RFC 3339 misdescribed in doc of date(1)

The manual for version 8.26 of coreutils, in the section on date(1)'s --rfc-3339 option, says of RFC 3339: This is a subset of the ISO 8601 format, except that it also permits applications to use a space rather than a `T' to separate dates from times. This description

bug#24349: Linux info date example

On 01/09/16 13:40, Sergiu Druta wrote: > Hello, > > Dear Sire/Madame > > > By checking *info date* examples, I've found a small mistake for one > example(see attached file). > > ~$ date -d 1may '+%B %-d > > In above example there is a single mark q

bug#24349: Linux info date example

Hello, On 09/01/2016 08:40 AM, Sergiu Druta wrote: ~$ date -d 1may '+%B %-d In above example there is a single mark quotation ( ' ) missing at the end of example. Thank you for the report. The attached patch (in your name) adds the quote. If you approve, and there are no other comments

bug#24349: Linux info date example

Hello, Dear Sire/Madame By checking *info date* examples, I've found a small mistake for one example(see attached file). ~$ date -d 1may '+%B %-d In above example there is a single mark quotation ( ' ) missing at the end of example. Not sure if this is so important but I decided to report

bug#23664: Date Problem: Wrong return using last month today (2016-05-31)

tag 23664 notabug thanks On 05/31/2016 12:14 PM, Felippe Silvestre wrote: > [root@superdssbox999 ~]# date > > Tue May 31 15:10:47 BRT 2016 > > > > [root@superdssbox999 ~]# date -d"last month" > > Sun May 1 15:10:52 BRT 2016 You've hit a FAQ;

bug#23270: Bug in 'date' command

Hello,   I recently discovered a bug, or at least unexpected behavior, about the ‘date’ command which I want to report.  The bug is related to the moment of ‘daylight saving time’ (summertime / wintertime)   On Monday the 28st of march at 0.15 I run an automated script with the command

bug#23035: date: regression in timezone printing (+%Z)

Hello, I think there's a small regression in coreutils 8.25 date command with regards to timezone printing on a machine without native 'timezone_t'. Example: $ uname -a SunOS unstable10x 5.10 Generic_147441-19 i86pc i386 i86pc $ export TZ=Asia/Tokyo $ ./coreutils-8.24/src/date +%Z JST

bug#23035: date: regression in timezone printing (+%Z)

8d3b0efa6319daa3fb7451582f9fda7db5f3c2e3 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Thu, 17 Mar 2016 10:35:18 -0700 Subject: [PATCH] date ls pr: fix time zone abbrs on SysV platforms The problematic code computed a struct tm in one time zone, and then printed it or converted it to a

bug#23008: Daylight Savings Time Bug in Date

tag 23008 notabug thanks On 03/13/2016 11:24 PM, Sarah Corriher wrote: > We detected a bug in the date program, which correlates to the daylight > savings time change. Thanks for the report. However, this is not a bug, but a FAQ that gets asked twice a year. See: https://www.gnu.org/so

bug#23008: Daylight Savings Time Bug in Date

We detected a bug in the date program, which correlates to the daylight savings time change. A day disappeared from the date program between 12:00 AM and 1:00 AM on 3/14/16. The date program began working as expected immediately after 1:00 AM. Here is the bizarre output that I got for basic

bug#22491: Incorrect date(1) man page about --iso-8601 example for GNU coreutils 8.25

Hi, In the date(1) man page, the --iso-8601 example is: 2006-08-14T02:34:56-0600 This should be: 2006-08-14T02:34:56-06:00 -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/&

bug#22491: Incorrect date(1) man page about --iso-8601 example for GNU coreutils 8.25

On 29/01/16 18:04, Vincent Lefevre wrote: > Hi, > > In the date(1) man page, the --iso-8601 example is: > > 2006-08-14T02:34:56-0600 > > This should be: > > 2006-08-14T02:34:56-06:00 Fixed in your name at: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=c

bug#22439: date -d @0 +%X returns 01:00:00

one. Using '-d @0' syntax specifies seconds-since-epoch in UTC timezone, regardless of your computer's timezone. But when the date is printed, it is converted to your computer's timezone - hence the offset. Examples: (on my computer, in which timezone = EST,-05:00) $ date -d '@0' W

bug#22439: date -d @0 +%X returns 01:00:00

Hi@all, tried this with Debian Jessy and openSUSE 13.1 If i specify -d 1970/1/1 it returns proper value of 00:00:00 thx

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

tag 22397 notabug close 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 17 22:00:00 EST 2016 > > To fix this, a wo

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

$> 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 17 22:00:00 EST 2016 To fix this, a work around for me now is: $> date -d"$(date -d"04:00") +1 day" Mon Jan 18 04:00:00 EST 2016 +AMD

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

To reproduce: LANG="mr_IN.utf8" date -d 'Wednesday' +%A I see the value मंगळवार This is the Marathi equivalent of Tuesday. LANG="mr_IN.utf8" date -d 'Wednesday' +%A returns the same string. Other Marathi weekdays are correct. Regards, Richie WCM-Q

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

tag 22183 notabug close 22183 stop On 16/12/15 06:42, Richard J. Cotton wrote: > To reproduce: > > LANG="mr_IN.utf8" date -d 'Wednesday' +%A > > I see the value > मंगळवार > > This is the Marathi equivalent of Tuesday. LANG="mr_IN.utf8" date -

bug#21186: date core with bad string

Hi there, I inadvertently discovered that the following bad input leads to a date core. While I accept that I was throwing garbage at poor old date, I thought that the resulting core merited a bug report. The string was: date +%s -d'TZ=America/Los_Angeles Tue, 14 Jul 2015 04:00:35 +' I

bug#21186: date core with bad string

unarchive 16872 forcemerge 21186 16872 stop On 04/08/15 12:36, Michael Moffatt wrote: Hi there, I inadvertently discovered that the following bad input leads to a date core. While I accept that I was throwing garbage at poor old date, I thought that the resulting core merited a bug report

bug#20850: acknowledged by developer (Re: bug#20850: Converting under Linux a by date calculated epochtime back with date, does not return the same data)

So when I attempted to convert it into epochtime with the date command in the first place, I was actually happy about I could do it just like that and did not dig any deeper into this. But apparently whatever character is between the DATESTAMP and the TIMESTAMP here, influences some kind

bug#20850: acknowledged by developer (Re: bug#20850: Converting under Linux a by date calculated epochtime back with date, does not return the same data)

DATESTAMP and the TIMESTAMP: 2015-06-18T06:27:01 So when I attempted to convert it into epochtime with the date command in the first place, I was actually happy about I could do it just like that and did not dig any deeper into this. But apparently whatever character is between

bug#20850: Converting under Linux a by date calculated epochtime back with date, does not return the same data

Good Morning, I am converting a timestamp into the respective epochtime number using the 'date' command from 'coreutils'. When I convert this back however, the result differs from the initial input. I'd expect the same, and which is the case actually under CygWin under WIN7. Under CentOS

bug#20850: Converting under Linux a by date calculated epochtime back with date, does not return the same data

tag 20850 notabug close 20850 stop On 19/06/15 10:03, Bahn, Ingo wrote: Good Morning, I am converting a timestamp into the respective epochtime number using the 'date' command from 'coreutils'. When I convert this back however, the result differs from the initial input. I'd expect

bug#20523: GNU coreutils 8.4 date: wrong day shift calculation at the spring daylight savings time cutover

into this I found the shell wrapper script to be at fault and specifically the GNU date program. Here is a simplified version to reproduce the bug: script: #!/bin/sh echo NOW is `date` echo TODAY is `date +%Y%m%d` echo YESTERDAY is `date -d 'yesterday' +%Y%m%d` echo 30 DAYS AGO

bug#20523: GNU coreutils 8.4 date: wrong day shift calculation at the spring daylight savings time cutover

On one of my production systems I do daily database dumps between midnight and 1am every day. I noticed on March 9th this year is was dumping the wrong day. Digging further into this I found the shell wrapper script to be at fault and specifically the GNU date program. Here is a simplified

bug#20523: GNU coreutils 8.4 date: wrong day shift calculation at the spring daylight savings time cutover

any daylight savings time hickups. It just never occured to me that “date” could be wrong and I thought running the cron job before the DST adjustment between 2 and 3 am should be safe. Alas this is not the case. - Markus On May 7, 2015, at 14:00, Bob Proulx b...@proulx.com wrote: Markus

bug#20523: GNU coreutils 8.4 date: wrong day shift calculation at the spring daylight savings time cutover

Markus Baur wrote: On one of my production systems I do daily database dumps between midnight and 1am every day. I noticed on March 9th this year is was dumping the wrong day. Digging further into this I found the shell wrapper script to be at fault and specifically the GNU date program. Here

bug#20203: add example to date man page

Please change -I[TIMESPEC], --iso-8601[=TIMESPEC] output date/time in ISO 8601 format. TIMESPEC='date' for date only (the default), 'hours', 'minutes', 'seconds', or 'ns' for date and time to the indicated precision. to -I[TIMESPEC

bug#20203: add example to date man page

On 25/03/15 23:58, 積丹尼 Dan Jacobson wrote: Please change -I[TIMESPEC], --iso-8601[=TIMESPEC] output date/time in ISO 8601 format. TIMESPEC='date' for date only (the default), 'hours', 'minutes', 'seconds', or 'ns' for date and time

bug#19856: Bad month translation printed with date command in Greek locale

On Fri, Feb 13, 2015 at 03:56:25PM -0700, Eric Blake wrote: It also looks like the POSIX wording is very specific on which of the two forms is genitive vs nominative In general such words (like genitive) are not appropriate. Different languages have different systems of flection, and the

bug#19856: Bad month translation printed with date command in Greek locale

Hello we are Nick Barkas and Ioannis Barkas from Greece. There is an annoying error in the date command for quite some time when using Greek locale. If date is instructed to print month and day of month, the translation is wrong and looks funny... You have to be able to write Greek in order

bug#19856: Bad month translation printed with date command in Greek locale

If I understand correctly, it doesn't appear that this is a bug that coreutils can fix, as POSIX implies (and many programs expect) that formats like %d and %B and %Y act independently of context. If it's any consolation, the default output of 'date' in the C locale: Thu Jun 28 15:10:00 PDT

bug#19856: Bad month translation printed with date command in Greek locale

[adding the Austin Group, as this is a POSIX question] On 02/13/2015 06:46 AM, Nick John wrote: Hello we are Nick Barkas and Ioannis Barkas from Greece. There is an annoying error in the date command for quite some time when using Greek locale. Thanks for the report. If date is instructed

bug#19856: Bad month translation printed with date command in Greek locale

On 02/13/2015 01:17 PM, Jilles Tjoelker wrote: The functionality already works in FreeBSD, for example: $ LC_TIME=el_GR.UTF-8 date +%d %B %Y 13 Φεβρουαρίου 2015 $ LC_TIME=el_GR.UTF-8 date +%OB %Y Φεβρουάριος 2015 It was implemented for Greek in 2001: https://bugs.freebsd.org/bugzilla

bug#19856: Bad month translation printed with date command in Greek locale

, without day mentioned). This feature was discussed here before, and an interpretation was issued for issue 8: http://austingroupbugs.net/view.php?id=258 The functionality already works in FreeBSD, for example: $ LC_TIME=el_GR.UTF-8 date +%d %B %Y 13 Φεβρουαρίου 2015 $ LC_TIME=el_GR.UTF-8 date +%OB %Y

bug#19856: Bad month translation printed with date command in Greek locale

On Fri, 13 Feb 2015 10:56:34 -0700, Eric Blake ebl...@redhat.com said: Coreutils will automatically pick up any fixes in glibc, you'll need to get it fixed there first. It would be nice to get POSIX to standardize %OB, but that would be easier if you could first get glibc to implement the

bug#19090: date bug?

Plato wrote: After I set the date sudo date 11172042 mo nov 17 20:42:00 CET 2014 The screen blanks. I am sure by now you have figured out that the screen blanker software is looking at the time as it passes by. If you set the date then the system time jumps from one time

bug#19090: date bug?

Hello, After I set the date sudo date 11172042 mo nov 17 20:42:00 CET 2014 The screen blanks. Is this a bug or is something else going on? The man page does not mention screenblanking. Also seen it on an other computer Running Debian Wheezy -- With kind regards

bug#19090: date bug?

tag 19090 notabug close 19090 stop On 17/11/14 19:45, Plato wrote: Hello, After I set the date sudo date 11172042 mo nov 17 20:42:00 CET 2014 The screen blanks. Is this a bug or is something else going on? The man page does not mention screenblanking. Also seen

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