I hope we all agree that "date -u" (UTC time) should produce the same time on every device (assuming they are sync'd properly).
Here is the output from dd-wrt, tomato, and x86 linux
====DD-WRT v24-sp2 (06/02/09) mega====
BusyBox v1.13.4 (2009-06-02 12:09:10 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
root@dd-wrt:~# date -u
Fri Jun 12 10:08:06 UTC 2009
====Tomato v1.25.1720====
BusyBox v1.14.0 (2009-05-25 16:08:27 PDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# date -u
Fri Jun 12 17:07:58 UTC 2009
====x86 (non-dd-wrt) linux distribution====
# date -u
Fri Jun 12 17:07:59 UTC 2009
Notice how Tomato and x86 linux have the same time for UTC (after accounting for the second it took to switch terminal sessions and execute the command)
DD-WRT is off by both the -7h offset for PDT and is fast by about 9-10 seconds.
This means there are 2 problems:
1) UTC time is wrong on dd-wrt
2) apparently it either doesn't update time via ntp often enough, or it only does it at startup. The uptime on the dd-wrt router is 9 days so I'm gaining about 1 second a day
Both Tomato (alternate wrt54g linux firmware) and DD-WRT are using busybox to implement the date command so unless there is a bug in busybox (or the C library it is compiled with), they should be outputing the same date value for UTC. Since they are not and it is unlikely there is a bug with such a fundamental function, the most likely explanation is DD-WRT is setting UTC to localtime (PDT masquerading as UTC in this example)
The second issue this brings up is time that is synced with NTP should never be off by 9-10 seconds unless something is wrong. Since I don't see ntpd running in the background, I'll assume that dd-wrt is supposed to periodically start up the process and sync the time. That doesn't appear to be happening here, or at least not happening often enough.
In Tomato they give you the option to sync the time every N hours so I assume they have a scheduled job to run the ntp sync. Previously I would have assumed DD-WRT also scheduled something to run every few hours, but with my time off by 9 seconds, I think that isn't happening.
After I reboot DD-WRT, it is no longer off by 9 seconds (though UTC time is still wrongly set to PDT/localtime)
Last edited by sfhub on Fri Jun 12, 2009 17:41; edited 3 times in total
I can understand if BrainSlayer lowers the priority to something low, but I don't understand (at least from the explanation given) why this is an "invalid" bug.
Maybe the title of the bug should be "UTC time is incorrect" and simply say "date -u" has the incorrect time.
I also thought it interesting that he believes an RTC by definition requires a battery buffer...
Anyway, this "quick triage" is simply BrainSlayer's style of dealing with the deluge of bug reports from users at all levels of experience and competence. And once he's made his mind up, it may take a while for him to see things differently. But I don't take it personally. 8)
I've added one more reply to the bug report, cleaned up the title a bit, and reopened it as "minor", even though IMO it's more serious than that. But I know if I re-open it as major it will just get closed and marked "invalid" again. Better to have it marked minor if that's what it takes to keep it in the pile of open bugs...
Edited to change "battery backup" to "battery buffer", to accurately quote BrainSlayer (sorry 'bout that...)
Last edited by SNR on Fri Jun 12, 2009 18:18; edited 2 times in total
Both Tomato (alternate wrt54g linux firmware) and DD-WRT are using busybox to implement the date command so unless there is a bug in busybox (or the C library it is compiled with), they should be outputing the same date value for UTC. Since they are not and it is unlikely there is a bug with such a fundamental function, the most likely explanation is DD-WRT is setting UTC to localtime (PDT masquerading as UTC in this example)
Thanks for comparing apples to apples here. My comparison of cygwin bash to busybox on DD-WRT was apparently giving BS some grief. But your example above proves beyond a doubt that this is definitely an issue with the time implementation in DD-WRT (not a busybox vs. GNU date issue).
sfhub wrote:
The second issue this brings up is time that is synced with NTP should never be off by 9-10 seconds unless something is wrong. Since I don't see ntpd running in the background, I'll assume that dd-wrt is supposed to periodically start up the process and sync the time. That doesn't appear to be happening here, or at least not happening often enough.
In Tomato they give you the option to sync the time every N hours so I assume they have a scheduled job to run the ntp sync. Previously I would have assumed DD-WRT also scheduled something to run every few hours, but with my time off by 9 seconds, I think that isn't happening.
If you check the timeline in Trac you can see several recent fixes for cron-related issues. Hopefully it's now possible to schedule a job to sync with ntp.
Edited to change "bash date" to "GNU date", as date is a separate executable in the GNU distribution and not actually part of the bash shell itself. Also edited to add this note about my previous edit.
Last edited by SNR on Fri Jun 12, 2009 17:58; edited 2 times in total
reopened it as "minor", even though IMO it's more serious than that.
As to the seriousness, I think if you are on an island and everyone you interact with is on the island and there is only one clock on the island, you can basically set time to whatever you want and things will mostly work.
The potential for problems to arise are most likely when you have to interact with folks outside your island who have no idea about your special rules regarding time.
The other place where you might have problems is around the Spring and Fall standard/savings switchovers where if you are treating localtime as UTC, there will be overlaps and black holes in the time graph used by the kernel where as if UTC was really UTC, the time graph will be continuous (and only your localtime, filtered display version of time, will have the overlaps and black holes)
I searched through the Tomato source for "UTC", "TZ", etc. but couldn't find anything. But the README says that Tomato is built by overlaying its source on top of the Linksys source (which explains why the Tomato tarball is so tiny). So Tomato may simply be using the Linksys time implementation?
Would be interesting to see how Tomato handles TZ descriptor strings...
As to the TZ descriptor strings, we already discussed you could generate descriptor strings algorithmically for minimal space, but really even if you were to stick them in a table (like the array that populates pop up list selector for Time Zone in DD-WRT) the memory/storage impact would be extremely minimal.
I mean what are we really talking about, 38 potential time zones (that is what I counted in DD-WRT config, excluding UTC, which has no DST) multiplied by 6char descriptor (PST PDT), for 228 *bytes*, or even less if you compress it?
BTW I miscounted earlier when I said 46char string, actually worse case is 52char but most often it will be much less, more like 26char because there are default values for many of the fields so they don't need to be specified. The max 56char full TZ string is not to be confused with the 6char calculation discussed in the previous paragraph which is just the 3char standard and daylight descriptor strings. DD-WRT specifies the start/end dst in a separate entry field, which would remain unchanged.
In Tomato the description for Pacific Time Zone is:
UTC-8:00 Pacific Time
In DD-WRT the description for the equiv time zone is:
UTC-8:00
but then there is another table, Summer Time (DST), to specify when DST starts/ends
Tomato does set UTC to UTC.
It also properly populates the /etc/TZ file so that all apps will default to using localtime without any extra effort.
I searched through the Tomato source for "UTC", "TZ", etc. but couldn't find anything. But the README says that Tomato is built by overlaying its source on top of the Linksys source (which explains why the Tomato tarball is so tiny). So Tomato may simply be using the Linksys time implementation?
There really isn't any "Linksys" time implementation.
There is only "Linux/Unix" time implementation. Time is fundamental and built into the kernel and is specified as seconds before/after epoch.
You probably mean Tomato is "setting" UTC time (which is converted to seconds since epoch for the kernel to use) and TZ the same way as the Linksys firmware. It is possible/probable, but I don't know how the stock Linksys firmware does this, so can't say for sure.
I do know that Tomato is setting UTC time and TZ the way they are expected to be set on any linux box using uClibc (micro lib C)
I also know that Tomato updates their packages to versions newer than what Linksys provides if appropriate. You can see the version of busybox they use (v1.14.0) is newer than even what the DD-WRT betas are using (v1.13.4).
In any event, I really don't think space is an issue for specifying DST and localtime in this case. At most we are talking about 38*52 or 1976 bytes in the worst case, and more likely less than 1K in the probable case.
Last edited by sfhub on Fri Jun 12, 2009 19:34; edited 1 time in total
I don't take it personally either, I'm mainly documenting the issue in as much detail as possible because I know in a few days the subject will be off my mind and I will start forgetting about it.
Figure if I, we, or someone else revisits it would be best to have that all written down somewhere.
There really isn't any "Linksys" time implementation.
There is only "Linux/Unix" time implementation. Time is fundamental and built into the kernel and is specified as seconds before/after epoch.
You probably mean Tomato is "setting" UTC time (which is converted to seconds since epoch for the kernel to use) and TZ the same way as the Linksys firmware. It is possible/probable, but I don't know how the stock Linksys firmware does this, so can't say for sure.
Yes, that's what I mean/t, and thanks for keeping us all clear on what we are referring to here.
I've downloaded the Linksys source to try and see what they do but I can't get the archive extracted without getting prompted to overwrite some "already existing" files that really don't already exist (seems to be a bug with 7-Zip). Will try again later with a different extraction tool.
[...] I'm mainly documenting the issue in as much detail as possible because I know in a few days the subject will be off my mind and I will start forgetting about it.
Figure if I, we, or someone else revisits it would be best to have that all written down somewhere.
Yes, that's what I'm doing also. Creating a time capsule of sorts, for future reference.
Everything else stems from that fundamental issue.
I've been wrestling with the question of whether DD-WRT is actually masquerading local time as UTC, or masquerading UTC as local time? :?
I think the answer depends on whether you focus on the descriptor strings or the displayed offset. So I didn't want to go that direction in the title of the bug report.
I've been wrestling with the question of whether DD-WRT is actually masquerading local time as UTC, or masquerading UTC as local time? :?
I think the answer depends on whether you focus on the descriptor strings or the displayed offset. So I didn't want to go that direction in the title of the bug report.
Actually it is very clear that DD-WRT is masquerading local time as UTC.
date -u
by definition produces the UTC time. UTC time will be the same everywhere. It's like asking what is the time in London when you are physically in NY and your friend is in CA. The time in London is the same for both of them. The individuals' "localtimes" (EDT, PDT) are different. For DD-WRT UTC time is different for every time zone. That is not correct behavior for properly configured Linux systems.
The Linux/Unix kernel is designed to work on UTC time (converted to seconds since epoch). It was designed this way specifically so it didn't have to deal with other timezones and DST offsets, simplifying time sync and time calculations. Timezones and DST are all handled after the fact by display filtering.
It sounds like the reasoning in the second paragraph of your quote is debating whether time should be (when I say UTC, I mean UTC converted to seconds before/after epoch):
1) stored as localtime with an offset used to get UTC
or
2) stored as UTC with an offset used to get localtime
I can tell you with absolute certainty on Linux/Unix systems it should be #2. Linux/Unix systems are designed to operate with an internal (kernel) base time of UTC.
This is explained in many places including (but not limited to) the Debian Linux system admin guide. I just chose this because it is convenient to link to, but the information in the quoted section is applicable to all Linux/Unix systems, not just Debian.
The time zone is needed because Unix computers keep time in Universal Time (UTC), and local time is calculated from this. UTC is solar time on meridian 0. UTC was previously called Greenwich Mean Time (GMT) because meridian 0 passes through the old Royal Observatory in Greenwich, which is part of London, England.
UTC is constant, and is not subject to Daylight Saving Time or other changes. This is what makes it useful for syncronising computers. As long as the base time is kept in UTC, computers all over the world can be synchronised and yet maintain their local time information.
Now, there is a compromise on some systems where the *hardware clock* is kept in localtime because it is also used by DOS (which doesn't understand time zones), and the Linux kernel will account for that and convert hwclock-localtime to UTC/Epoch automatically. That is what the "Use Localtime" option you mentioned earlier does. However since
1) there is no hw clock on wrt54g
2) even if there were, you aren't sharing the wrt54g with DOS
there should be no reason for this type of workaround in dd-wrt for wrt54g. Further even if the "Use Localtime" workaround was being used (let's say on x86 dd-wrt), the linux kernel will still keep base time as UTC/Epoch and "date -u" will stil display the correct UTC time. It is only the hwclock that will display something different than the kernel time.
So I will make the claim that "date -u" shows the kernel time in UTC with no offsets. Since on DD-WRT the output of "date -u" matches what my local time should be, that means to me that DD-WRT has set the kernel/UTC/epoch time to my local time, thus local time is being masqueraded as UTC.
