Topic: Incorrect timezone in date

The content of this topic has been archived on 11 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Page 1 of 1

Post #1

harry0

30 Apr 2007, 21:03

First of all I would like to thank all of the developers for taking the time to provide such a valuable project.

I am having a weird problem with the date on my Buffalo router running WhiteRussian 0.9. The timezone is set according to the documentation to 'EST5EDT,M3.2.0,M11.1.0' as set in /etc/TZ. When I type 'date' I get the correct output, eg: 'Mon Apr 30 15:56:30 EDT 2007'. When I type 'date -R' I get something I didn't expect, eg: 'Mon, 30 Apr 2007 15:56:30 +0400'. Note that the timezone is '+0400' and not '-0400'. This wouldn't be such a problem, except that I am using ssmtp to send status emails to myself and they are all timestamped 8 hours off.

If this provides any additional insight, I am using ntpclient to keep the time correct since the router drifts a bit. I use the cron command 'ntpclient -c 1 -s -h `nvram get ntp_server`' to set the time once a day (as suggested in the documentation). I cannot see where the problem lies. Any suggestions?

TIA!!

-- Harry O.

Post #2

Bill_MI

1 May 2007, 00:48

root@OpenWrt:~# date
Mon Apr 30 19:30:36 EDT 2007
root@OpenWrt:~# date -R
Mon, 30 Apr 2007 19:30:45 +0400
root@OpenWrt:~# cat /etc/TZ
EST5EDT,M3.2.0/2,M11.1.0/2
root@OpenWrt:~# which date
/bin/date
root@OpenWrt:~# ls -alrt /bin/date
lrwxrwxrwx    1 root     root            7 Feb  3 10:49 /bin/date -> busybox

Same here on a WRT54Gv3. Doesn't this have to be a busybox bug?

Post #3

JimWright

1 May 2007, 01:27

It looks like this is expected behavior, the -R parameter outputs date and time in RFC 2822 format, more info on that here:

http://www.faqs.org/rfcs/rfc2822.html

Section 3.3 holds the key:

The zone specifies the offset from Coordinated Universal Time (UTC, formerly referred to as "Greenwich Mean Time") that the date and time-of-day represent. The "+" or "-" indicates whether the time-of-day is ahead of (i.e., east of) or behind (i.e., west of) Universal Time. The first two digits indicate the number of hours difference from Universal Time, and the last two digits indicate the number of minutes difference from Universal Time. (Hence, +hhmm means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) minutes). The form "+0000" SHOULD be used to indicate a time zone at Universal Time. Though "-0000" also indicates Universal Time, it is used to indicate that the time was generated on a system that may be in a local time zone other than Universal Time and therefore indicates that the date-time contains no information about the local time zone.

Post #4

harry0

1 May 2007, 01:35

I read the RFC too. And I think they mean that east is + and west is - (and NY is west of Greenwich). That's why I still cannot understand this:

in Linux:

[root@linux ~]$ date -R
Mon, 30 Apr 2007 20:28:24 -0400

on the router:

root@OpenWrt:~# date -R
Mon, 30 Apr 2007 20:28:50 +0400

-- Harry O.

Post #5

Bill_MI

1 May 2007, 03:49

Harry, after years of looking at email headers EST (-0500) and EDT (-0400) are second nature. +0400 is somewhere in the middle east so I saw your point immediately.

It's not the extra correction string, either. I set to straight "EST5EDT" and -R continues to output +0400.

Post #6

JimWright

1 May 2007, 05:11

For the record, my brain hurts every time I have to read RFCs...

OK, I've read through that paragraph a few more times, and it's slowly sinking in. Say it is 11am UTC. Eastern time is 5 hours earlier (-0500), and the east coast of the US is also west of UTC. So, the negative value is correct for EST. So, the RFC matches what we've all come to read in email headers.

So, this leads us back to this being a bug in busybox. I'm running busybox 1.4.0-1 here, and I'm seeing the same issue, so I do agree that this is definitely a bug in the date command showing a positive value instead of a negative one.

Post #7

kebul

2 May 2007, 18:09

This bug has been already solved.
See 0000336: [PATCH] strftime() returns invalid timezone
But White Russian is using the old uClibc 0.9.27.
We are working in the X-Wrt to include it in the next build.
For now you can use the UTC switch to get the proper time and date:
date -u -R

Post #8

JimWright

2 May 2007, 21:06

Will that be something that can be installed as a package? I'm running a recent (0.9) build of X-Wrt already.

Post #9

kebul

4 May 2007, 01:07

The uClibc package will have the increased release number (10).
I think that updating the library would have the same effects like updating the busybox.
I would not recommend it therefore.

The discussion might have continued from here.

Page 1 of 1