Date/time msgtrans error

I reported this one to Sprow, but he didn’t seem to be able to reproduce. I see it quite a lot with both ARMX6 and Titanium boards, so I thought I’d ask if anyone else has come across this (and I may have new info to add, too).

Basically, after trying to access the Time screen in !Configure (or *time at command line) generates a “Message token th not found” (or similar MsgTrans error).

Today, for example, I took a “clean” machine (no modifcation to cmos settings) and set the clock more-or-less correctly.

I ticked Automatic DST correction – time left on “Manual”.

Then turned on networking, and reboot.

The problem occurred – couldn’t get into Time config to enable “set from internet” because “Message token th not found”.

*time also gave same error.

Rebooted, same error.

*unplug showed no modules unplugged.

On a whim, I tried *configrue DST (overriding AutoDST) and rebooted. This time I could set the clock/time just fine. Of course, this could be pure co-incidence.

Has anyone else had trouble with AutoDST setting (when a clock or clockboard is present)?

I don’t recall this error occuring in the past, but have seen it in the last 6-9 months or so. That being said, I’ve seen it on Ti board which would have been running 5.24.

Has anyone else had trouble with AutoDST setting (when a clock or clockboard is present)?

Yes (I think).

I had a mini.m with no internet connection, so time was languishing at January 1900. Setting up for the first time I encountered the error ‘message token message token D01 not found not found’ when setting the time. I also observed that the ROM was announcing itself as 30 Jan 2019 (the date of the MOS utilities) rather than its build date of 1 Feb 2019. Selecting ‘full info’ for a directory listing produced a window where the space normally occupied by time and date was blank white space. Later on the same action on a directory window (selecting ‘full info’) produced just the first file in the directory and the message token error.

The error was resolved by deleting !Boot and replacing it by a fresh backup – stupidly I didn’t rename the !Boot that produced the error for analysis. So it may be assocviated with CMOS settings as I noticed that the TCP/IP had been set to the default (on) and back to off without me touching configure.

Could it be some sort of stack problem associated with the ‘default’ January 1900 date? There were some recent changes associated with deafult dates, I think.

Yes, I just built a mini.m today as well. On this one, I had TCP/IP on, but didn’t set AutoDST. Since TCP/IP was on by default, I just went in and sync’d the time without issue, then set DST (not AutoDST).

All seems fine on a reboot.

This is same disc image as yours, Chris.

I may be wrong on the AutoDST business, but it was the only thing earlier that seemed to fix the problem.

That being said, it does seem a touch spasmodic, as in the past I’ve done various things (eg. nettime_kick) to seemingly “fix” it successfully, which makes me think there may be more to it than meets the eye.

because “Message token th not found”.

That’s odd.

If/when this happens again, can you open $ in ResourceFS, then go into Resources.UK and open up Messages. The “th:” tag ought to be about halfway down.

Hmm… Try also *Territory to make sure it’s really set to UK.

If you specify *Territory UK, does that fix it?

Sorry to leave this for a month, but just encountered it again. Territory is set to UK, Rick. It seems to be caused by a combination of AutoDST, set time from internet, and having hardware RTC. Don’t *configure DST (which unsets autodst) fixed it right up again.

Of course, the reboot after changing cmos settings may have helped too, but there certainly seems to be a pattern. Since I’ve seen it on both mini.m and Titanium, both of which have hardware RTC, I’m wondering if it is somehow attempting to act on AutoDST before internet time sync has occurred or something. Not sure. Anyway, just thought I’d follow this up again having seen it again.