4

Running the following command at the xen-servers (either DOM0 or DOMU) at $company gives me a negativ number, on every other system zero (0) (even in my cygwin).

date -d "1970-01-01T00:00:00" "+%s"

$TZ is unset, /etc/localtime is the same file as /usr/share/zoneinfo/UTC

date is in version 8.12 from the GNU coreutils. What went wrong here? What additional informations may be needed?

0

2 Answers 2

2

if $TZ is unset and /etc/localtime is UTC then why are you using timezone T (Tango) in the date command?

On my system I have a localtime of EDT.

# date
Wed Mar 18 12:39:03 EDT 2015

# date -d "1970-01-01 00:00:00" "+%s"
18000

If I force it to Tango then I get a negative number:

# date -d "1970-01-01T00:00:00" "+%s"
-25200

If I change my timezone to UTC it will work as expected:

# export TZ=UTC
# date
Wed Mar 18 16:41:23 UTC 2015
# date -d "1970-01-01 00:00:00" "+%s"
0

from the date man page:

DATE STRING
       The  --date=STRING  is  a  mostly  free  format human readable date string such as "Sun, 29 Feb 2004 16:21:42
   -0800" or "2004-02-29 16:21:42" or even "next Thursday".  A date string may contain items indicating calendar
   date,  time of day, time zone, day of week, relative time, relative date, and numbers.  An empty string indi-
   cates the beginning of the day.  The date string format is more complex than is easily documented here but is
   fully described in the info documentation.

As you can see it is a "mostly free format human readable date", it will pick up the timezone from anywhere it sees fit. It is very easy to test it.

For example:

# date
Wed Mar 18 13:05:42 EDT 2015

now with Tango time:

[root@wailea ~]# date -d "2015-3-18T13:05:42" 
Wed Mar 18 02:05:42 EDT 2015

now with Tango time at the end:

[root@wailea ~]# date -d "2015-3-18 13:05:42 T" 
Wed Mar 18 02:05:42 EDT 2015

now Zulu time:

[root@wailea ~]# date -d "2015-3-18Z13:05:42" 
Wed Mar 18 09:05:42 EDT 2015

I think you can see the point. If you are not familiar with military timezones here is the list: http://www.timeanddate.com/time/zones/military

You can also try to use zdump to see if your zone file is not really what you are expecting:

Zdump prints the current time in each zonename named on the command line.

# zdump /etc/localtime
/etc/localtime  Wed Mar 18 21:21:04 2015 EDT
5
  • My reading of the info pages for date is that "T" and " " can be used equivalently to separate date and time. I don't see anything (in section 28.5) saying that "T" implies special handling of the time but you're obviously getting different behaviour. Have you got a reference for the "tango" behaviour? I get the same with T and space (using UTC or Europe/London which is local timezone). Mar 18, 2015 at 16:56
  • I updated my answer but just to be clear, I am working with Centos/RedHat systems.
    – Ricardo
    Mar 18, 2015 at 17:25
  • also test your zonename file with zdump as explained above, maybe it will reveal that somebody renamed the original UTC file with something else
    – Ricardo
    Mar 19, 2015 at 1:23
  • Ok, zdump gives the right UTC timezone. But I would never think off that date can't parse ISO-8601 in the right way -_- Mar 20, 2015 at 13:50
  • @PaulHaldane The info page for date at those systems doesn't state anything about ' ' and 'T' as seperator or any seperator at all. Seems like date 8.12 is just too plain old. Apr 7, 2015 at 12:16
0

When specifying the date and time in ISO 8601 format, you need to append a Z if you want to force it to be handled as UTC:

$ date -d "1970-01-01T00:00:00Z" "+%s"
0

Alternatively, you can use a UTC offset of either +0 or -0 instead of Z.

2
  • At least with date 8.12 this gives a »date: invalid date `1970-01-01T00:00:00Z'« Mar 20, 2015 at 13:52
  • Must be new, then. I was testing with 8.23. Mar 20, 2015 at 14:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .