0

This question already has an answer here:

I'm having some weird issues with GNU coreutils date v8.4 (CentOS) that aren't occurring in v8.21 (Ubuntu/Mint).

On v8.4, I get the following output (I'm in PST):

$ date --version | head -n 1
date (GNU coreutils) 8.4
$ date -d '2014-11-08'
Sat Nov  8 00:00:00 PST 2014
$ date -d '2014-11-08T00:00:00'
Fri Nov  7 09:00:00 PST 2014

I'm assuming it's trying to timezone-correct for UTC, even though I didn't request it and this behavior doesn't occur on my local Linux Mint machine.

Okay, so I'll add a timezone specifier, as specified by W3. On my machine:

$ date --version | head -n 1
date (GNU coreutils) 8.21
$ date -d '2014-11-08T00:00:00-0800'
Sat Nov  8 00:00:00 PST 2014
$ date -d '2014-11-08T00:00:00-08:00'
Sat Nov  8 00:00:00 PST 2014

Great. But on CentOS:

$ date --version | head -n 1
date (GNU coreutils) 8.4
$ date -d '2014-11-08T00:00:00-0800'
date: invalid date `2014-11-08T00:00:00-0800'
$ date -d '2014-11-08T00:00:00-08:00'
date: invalid date `2014-11-08T00:00:00-08:00'

EDIT: Another one that doesn't work, using date's own output:

$ date -d "$(date -Ihours)"
date: invalid date `2014-11-08T13-0800'

The following does work:

$ date -d '2014-11-08 00:00:00 -08:00'
Sat Nov  8 00:00:00 PST 2014

but, due to completely unrelated requirements, I can't have any spaces in my date string.

I'm quite perplexed. I looked for recent changes to date but didn't see anything that looks promising.

My question: How can I get date to either not change my timezones at all (preferable), or accept timezone input from a human-readable string without spaces?

marked as duplicate by Gilles shell Nov 8 '14 at 23:43

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • @Costas mmm, close, but I don't think so. I would rather have it be timezone-agnostic instead of picking a specific timezone. Just "use local time everywhere." – wchargin Nov 8 '14 at 22:15
2

Check again the link you posted, there's a commit message:

date: support parsing of ISO-8601-with-"T" dates

It was implemented in coreutils 8.13 (see changelog).

  • If it was implemented in v8.13, then why does behavior differ between v8.21 and v8.4? – wchargin Nov 8 '14 at 22:13
  • Thanks—I saw that link but didn't look to closely because it was so short. I now notice the +0 portion at the end of the line added to tests/misc/date. But it looks like this is only a test case, not the actual implementation, right? – wchargin Nov 8 '14 at 22:14
  • 1
    1. Because 8.4 < 8.13 < 8.21 and 2. Yes, that's only a test case, the actual implementation is in lib/parse-datetime.c – don_crissti Nov 8 '14 at 22:39
  • Oh! I had assumed that v8.13 meant v8.1.3. Thanks for the clarification. – wchargin Nov 8 '14 at 22:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.