Opened 8 years ago

Closed 3 years ago

#1115 closed (fixed)

UTC time ("date -u") is incorrect

Reported by: SNR Owned by: BrainSlayer
Keywords: Cc: fejesjoco, Michael Elsdörfer, wenzhuo@…


Bug noted in latest builds (possibly earlier but I wasn't paying attention); bug definitely present in 12220 thru 12262:

Based on the output from the date command, DD-WRT is defaulting to UTC, regardless of the fact that I've told it I'm in UTC-8 and currently observing DST.

Here's the output from a telnet session to DD-WRT using the date command with various formatting options. Each format type includes an example both with and without the -u UTC qualifier. Note that DD-WRT output defaults to either UTC or 0000 (depending on the format), but it never shows anything except this TZ/offset, regardless of the use of -u:

root@DD-WRT:~# date
Thu Jun 4 19:31:28 UTC 2009

root@DD-WRT:~# date -u
Thu Jun 4 19:31:32 UTC 2009

root@DD-WRT:~# date -R
Thu, 04 Jun 2009 19:31:37 +0000

root@DD-WRT:~# date -u -R
Thu, 04 Jun 2009 19:31:40 UTC

root@DD-WRT:~# date -Iseconds

root@DD-WRT:~# date -u -Iseconds

Compare this to the output from the same command in Cygwin bash on my Windows PC. Note that the correct TZ string PDT or offset value -0700 is displayed when the -u qualifier is not present. Also note that the actual date & time rolls forward seven hours (as expected) with with the use of -u:

root@mypc ~
$ date
Thu Jun 4 19:36:31 PDT 2009

root@mypc ~
$ date -u
Fri Jun 5 02:36:34 UTC 2009

root@mypc ~
$ date -R
Thu, 04 Jun 2009 19:36:42 -0700

root@mypc ~
$ date -u -R
Fri, 05 Jun 2009 02:36:47 +0000

root@mypc ~
$ date -Iseconds

root@mypc ~
$ date -u -Iseconds

Another possibly related issue:

With the NTP Client "Disabled", the router time exactly equals the number of seconds uptime, counted from the beginning of the usual Unix/POSIX time epoch of Jan 1 1970 00:00:00 UTC. So the "NTP Client" radio button is not exactly that, but rather a "Unix time vs. UTC" radio button.

See my posts in this Forum thread for more info:

Change History (28)

comment:1 Changed 8 years ago by BrainSlayer

Resolution: invalid
Status: newclosed

cywin bash is not busybox ash, beside this the date command has nothing todo with the shell and once again the cygwin date command has nothing todo with the busybox date command which is a different lightweigth implementation

NTP updates the time based on the settings you did. if ntp is not configured the time starts at zero for sure since there is no time configured, so this report is more than just sarkastic. as the date command shows in its output, the output is formated to UTC. so this report is wrong, it simply works as it should since the UTC time is correct.

comment:2 Changed 8 years ago by SNR

Resolution: invalid
Status: closedreopened


I'm not trying to be sarcastic. I just assumed that these devices have a realtime clock and the equivalent of a PC BIOS that maintains current date and time until the power is interrupted. If this is not the case then I apologize for my ignorance.

I only included the cygwin bash examples to show how one would expect offsets to appear in the date command. uClib does have the ability to maintain an offset from UTC internally, as opposed to redefining UTC to be equivalent to the local offset from UTC (which is what DD-WRT appears to be doing). See

In the Forum thread I mentioned above, user "sfhub" provided some very useful information as to how this might be accomplished with very little effort and minimal memory/NVRAM footprint. No offset-to-TZ mapping table would be required, as the TZ descriptor string could be generated algorithmically on-the-fly. In fact, one could probably even call all time zones "UTC", as long as the OS is maintaining the offset from actual UTC internally, so that applications which require this offset will have it available. sfhub noted that SMTP is one such application; and there are probably others.

Thanks. (Peter)

comment:3 Changed 8 years ago by BrainSlayer

Resolution: invalid
Status: reopenedclosed

no it has no realtime clock, since there is no battery buffer on it. and we are not talking about uclib, we are talking about busybox which implements the date command. so see the non UTC time you must set the TZ environment variable. but this is not required in dd-wrt, since the gui handles it by itself. we force to use UTC at commandline to keep cron and other timing services stable

comment:4 Changed 8 years ago by SNR

priority: majorminor
Resolution: invalid
Status: closedreopened
Summary: DD-WRT not paying attention to the specified Time Zone offsetDD-WRT not maintaining the specified UTC offset internally

... but busybox date and the GNU date command both implement similar option sets. They both include the -u option. In GNU this means "print or set Coordinated Universal Time", while in busybox it means "Work in UTC (don't convert to local time)". There's no essential difference in the -u option for these two date commands, is there?

My original bug report includes date output from busybox on DD-WRT both with and without the -u option, and in both cases the output is exactly the same. This should not be the case when I have the GUI set to -0800 (my local offset). Here's some of that sample output again:

root@DD-WRT:~# date Thu Jun 4 19:31:28 UTC 2009

root@DD-WRT:~# date -u Thu Jun 4 19:31:32 UTC 2009

I do understand that it is simply "easier" to implement what is essentially a single timezone. But this method does not provide a timezone offset to other applications that need it (e.g. message timestamps for SMTP). It's also quite confusing when you first see it in action (if that wasn't the case, then I wouldn't have posted this bug report). And I probably also added to the confusion with the original title of my report; so I've cleaned up the title a bit without changing the original intent.

(Reopening this ticket again as a lower priority so that hopefully the issue may someday get addressed...)

comment:5 Changed 8 years ago by BrainSlayer

as i said you only need to set the TZ environment variable correct

comment:6 Changed 8 years ago by sfhub

This is not an issue about timezones, offsets, or DST.

The issue is the UTC time is set to the incorrect value by DD-WRT.

date -u

is a representation of kernel time in UTC. It is supposed to produce the same time (regardless of your local time zone) for every Linux/Unix? system that is properly time synced. If I am in New York and my friend is in San Francisco and someone asks us what the time is in London, we will both have the same answer. In DD-WRT if you ask the person in NY what is the time in London, they will reply with the time in NY. The SF person will reply that the time in London is time in SF.

For DD-WRT, "date -u" only produces the correct time if configured your router as London/GMT/UTC time zone, otherwise for every other time zone you configure in the web UI, DD-WRT will have the wrong time for UTC.

Everything else stems from that fundamental problem. Since the kernel/epoch/UTC time is set incorrect, you cannot set TZ to the standard values because all those offsets are offsets off of UTC, which is set incorrect to start with. You can put fake TZ variable information to get the 3 character string to show up in the date command, but the time for UTC (date -u) is still wrong regardless of any cosmetic workaround one might apply. This again is because UTC (kernel time) is set incorrect to start with and no amount of TZ offsets will fix that.

comment:7 Changed 8 years ago by sfhub

In case it wasn't clear in the previous comment, instead of setting the kernel time to UTC, DD-WRT sets the kernel time to whatever ones localtime is.

Basically on every Linux/Unix? system with properly sync'd time, the output of "date -u" should match the time found here:

In DD-WRT, UTC time doesn't match the UTC time everyone else is using, unless you are living in London/GMT timezone and have thus configured your DD-WRT for that timezone. The reason this is happening is because DD-WRT is setting kernel/epoch/UTC time to your localtime.

comment:8 Changed 8 years ago by fejesjoco

comment:9 Changed 8 years ago by fejesjoco

Cc: fejesjoco added

comment:10 Changed 8 years ago by nema32

This seems to be causing me a problem with rsync from optware. When files are sync'd to the dd-wrt router, they end up with the wrong timestamps.

Router is at UTC-8. File modified at 08:00 UTC is sync'd. ls -e -l <file> shows it modified at 08:00 instead of 00:00. (-e required because 08:00 is in the future-- UTC-8 is 00:00)

Essentially, all files sync'd with rsync end up with timestamps in the future. This causes severe problems for other sync tools operating through samba shares.

comment:11 in reply to:  10 Changed 8 years ago by nema32

Replying to nema32: I was able to work around my rsync problem by setting the router to operate at UTC.

comment:12 Changed 7 years ago by Michael Elsdörfer

Cc: Michael Elsdörfer added

comment:13 Changed 7 years ago by star

Summary: DD-WRT not maintaining the specified UTC offset internallyUTC time ("date -u") is incorrect

I have retitled this bug to more accurately describe the issue. Please see sfhub's earlier comments in this report, or in extremely detailed posts in about the last half of this thread.

In short:

I'm located in EST (UTC -5hrs). As of this writing, UTC should currently be approx. 2:53AM.

On a Solaris 10 system with proper timekeeping implementation:

# date -u; date
Thursday, November 11, 2010  2:54:40 AM GMT
Wednesday, November 10, 2010  9:54:40 PM EST

On DD-WRT, however:

root@SNRouterCore:~# date -u; date
Wed Nov 10 21:54:40 UTC 2010
Wed Nov 10 21:54:40 UTC 2010

The "date -u" command should *never* yield anything but GMT time, and should only match localtime if you are currently in GMT. sfhub's notes show the exact point in the code where improper use of UTC (determining localtime as an offset of UTC, then setting UTC to that localtime value) occurs for whatever reason. He also gives a busybox vs busybox example of the above test here, in case for some reason the Solaris comparison is not accepted.

This issue is causing my SSL certificates to require a waiting period equal to my UTC offset (I'm in EST, so currently 5 hours) before they can be used for OpenVPN authentication on the router (running build 14896). At that point, the GMT timestamp on the "easy-rsa" generated certs is finally surpassed by the "localtime-as-UTC" as set on the router, allowing the cert to become valid and the TLS handshake to succeed. Any creative uses of the TZ variable still just amount to a band-aid for an inherently flawed implementation of UNIX timekeeping.

comment:14 Changed 7 years ago by Ivan Apolonio

This issue affects every application that checks if clocks are synchronized, such Kerberos authentication and DNS updates using TSIG. In my case, I'm trying to update my domain name using TSIG and I got this message:

; TSIG error with server: clocks are unsynchronized
update failed: NOTAUTH(BADTIME)

Although both ends are NTP syncrhonized, showing the same time, I figured out the cause by issuing the date -u command. The dd-wrt aways sets its clock using local time in UTC timezone, instead of setting its clock with the true UTC timezone and then shifting the specified timezones (in my case UTC-3) to show the correct local time.

To workarround this issue, I had to left my time configuration with no timezones shifting to match my local time, and thus my dd-wrt shows the UTC time. This is not the best solution, but at least I can syncrhonize my DNS entry.

Someone, please solve this issue. Thanks!!!

Ivan Apolonio

comment:15 Changed 6 years ago by Sash

Resolution: wontfix
Status: reopenedclosed

sorry guys but any sort of additional software via optware or whatever ist officially supported and receives no problemsolving from us.

comment:16 Changed 3 years ago by wenzhuo

Resolution: wontfix
Status: closedreopened

I am afraid the kernel clock (system clock) in not set to UTC, but the local time of the timezone specified at the bottom of the Basic Setup page. This is a bug. The kernel clock should always be set to UTC. See

I'm located in UTC+8:00 timezone, and the local time now is 21:35.

root@DD-WRT:~# date
Sun Apr 20 21:35:16 UTC 2014
root@DD-WRT:~# date -u
Sun Apr 20 21:35:18 UTC 2014

If I set the TZ environment variable correctly, I get the local time 8 hour later than the correct time.

root@DD-WRT:~# TZ=CST-8 date
Sun Apr 21 05:35:39 CST 2014
root@DD-WRT:~# TZ=CST-8 date -u
Sun Apr 20 21:35:40 UTC 2014

As you can see, the kernel clock is eight hours ahead of UTC time, which is 13:35.

Last edited 3 years ago by wenzhuo (previous) (diff)

comment:17 Changed 3 years ago by wenzhuo

Cc: wenzhuo@… added

comment:18 Changed 3 years ago by wenzhuo

Judging from do_ntp() (in ntp.c), dd-wrt sets the system clock to localtime (UTC+offset), and sets the RTC, if available, to localtime too. This breaks time-sensitive programs such as openvpn and nsupdate, and also makes the timestamps of files created by ftp/samba servers wrong. The Unix system clock always counts the number of seconds since the Epoch(00:00:00 Jan.1, 1970, UTC). It is a good practice to keep the RTC(the hardware clock) in UTC as well. When local time representation is needed, we should call localtime(3), which converts the system clock to local time according to the TZ environment variable.

ntpclient should be able to set the kernel clock to UTC correctly,but do_ntp(), which is said to be invoked on an hourly basis, will set the kernel clock back to localtime.

comment:19 Changed 3 years ago by wenzhuo

Owner: changed from somebody to BrainSlayer
Status: reopenednew

BrainSlayer?, please revisit this issue

comment:20 Changed 3 years ago by wenzhuo

Steps to reproduce the problem

  1. Set timezone to UTC+08:00 and reboot
  2. Compare date +%s before and after running ntpclient
    root@DD-WRT:~# date +%s; ntpclient && date +%s
    root@DD-WRT:~# echo $((1399337294-1399366094))

comment:21 Changed 3 years ago by binary

For me, this problem at least affects openvpn, which is officially supported by dd-wrt. I live in GMT-7. The certificates need to wait 7 hours to be considered valid by the openvpn server on DD-WRT

comment:22 Changed 3 years ago by Kong

Resolution: worksforme
Status: newclosed

Just set the correct timezone through startup command e.g.:

echo 'your timezone' > /tmp/TZ

See openwrt timezone list.

comment:23 Changed 3 years ago by wenzhuo

Resolution: worksforme
Status: closedreopened

It's not a localtime conversion issue. The issue is that do_ntp() resets the kernel clock to the wrong time, if timezone is set to anything other than UTC!

comment:24 Changed 3 years ago by Kong

Resolution: worksforme
Status: reopenedclosed

Set Timezone to UTC. Set DST to none.

echo 'CET-1CEST,M3.5.0,M10.5.0/3' > /tmp/TZ

root@DD-WRT:~# date Tue May 27 11:05:25 CEST 2014

root@DD-WRT:~# date -u Tue May 27 09:05:27 UTC 2014

Works absolutely fine.

comment:25 Changed 3 years ago by wenzhuo

Resolution: worksforme
Status: closedreopened

Sorry, it's a workaround we bug reporters have been using for a long time. But, resetting kernel clock to local time is simply wrong. The solutions is: Don't reset kernel clock to localtime in do_ntp(), and set the TZ environment variable properly for programs.

comment:26 Changed 3 years ago by Kong

No "it is not" a workaround you have been using for a long time, since I just recently added the possibility to use /etc/TZ:

The DST/Timezone code in dd-wrt is of course outdated and we consider a rewrite, but as you can see by the above addition of TZ this was never intended before.

Thus no bug but an enhancement that requires a redesign/rewrite of the code. I discussed this with BS and he has no objection.

comment:27 Changed 3 years ago by wenzhuo

ok, i was referring to the setting timezone to UTC part. good to know you are working on it.

comment:28 Changed 3 years ago by Kong

Resolution: fixed
Status: reopenedclosed

Fixed in r24330

Note: See TracTickets for help on using tickets.