EdgeRouter Lite & EdgeRouter 4: date command ignores timezone, shows UTC

If you read back, I think we already covered that intensively. Like I said, I have two Octeon devices and they're both exhibiting it. All my other hardware (ath79, mt7621, x86/64, ...) prints local time without complaining.

No all of them have it removed. My ath79 / ipq40xx / mt7621 / realtek devices all show CET correctly. It's just the Octeon devices deviating.

All of them use the same config settings concerning time etc.

Does any of them have a real real-time clock?

Thought about that too but shouldn't there be a /dev/misc/rtc then? Because that's missing. I do see the boot log printing "Switched to clocksource OCTEON_CVMCOUNT" (see opening post). When I look that up online I get:

"The clocksource concept represents the generic API for clock sources management in the Linux kernel."

Found this BSD mailing list thread though and that suggests the EdgeRouter Lite at least doesn't have one.

I don't see any battery either on the EdgeRouter Lite board (picture of the original version, courtesy of SmallNetBuilder):

Edit: I did find this old OpenWrt bug that seems related (and seems to rear its head once in a while), but no conclusive solution here. Already tried the busybox date -k command as well as removing/reloading the xt_time module, still UTC.

I can override the timezone Busybox uses by issuing TZ=CET date, but that's just a workaround. env prints no TZ value though, not on a functional system, nor on the EdgeRouters. So that's not the issue. The output looks identical on both systems as well.

Nope, TZ=CET doesn't seem to help one bit.

Hi

I have the same problem on EdgeRouter Lite 3 with OpenWrt 19.07.7.

I used strace tool to track which system calls were made.

3 lines of output show what is wrong:

strace date

...
open("/etc/TZ", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=27, ...}) = 0
mmap(NULL, 6953200402636640000, PROT_READ, MAP_SHARED, 3, 0) = -1 ENOMEM (Out of memory)
...

Second parameter of mmap function should be 27 (st_size from fstat function)
instead of 6953200402636640000,
so date can't read content of TZ file.

Now, I have no spare time to look at source files, but maybe someone could do that.

Some tips:
fstat() vs. fstat64()?
type casting?

Regards

3 Likes

I just took a look on mine, and the contents of /etc/TZ (symlink to /etc/localtime, which is symlink to /tmp/localtime) are quite a mess.

On another OpenWrt device (non-octeon) the content of TZ is what I expect: ("EST5EDT,M3.2.0,M11.1.0")

Editing /tmp/localtime and fixing its contents didn't help the 'date' command work (and would be lost on restart), but it looks like the problem also exists in whatever code writes out the /tmp/localtime file, too.