开云体育

On 2/20/2025 9:50 PM, Dan Boudreau via groups.io wrote:

Hi Dennis,
I believe you can change/stop the clock using the fast clock tool.

I _do not know_ if the various JMRI uses of "date" use the "fast-clock" date or the "real-time" date. That is possibly a different question!

On the question of JMRI's "fast-clock":

While JMRI's fast clock CAN support a "fast-time_ date, I haven't found a way to set that "fast clock" date via a simple GUI operation.

I have been able to reference the fast clock's "date" via Jython accesses. And I have been able to set the fast clock's "date" via a Jython script. If interested in Jython access to the JMRI fast-clock "date", let me know...

I believe that the JMRI "fast clock" date is established at the time that JMRI starts, at the actual real-time date, and that it probably increments the date every time the fast-clock rolls from 11:59pm to 12:00am.

I suppose that a JMRI developer could update the fast-clock mechanism to provide a GUI that can adjust the "date" - probably via an update to the existing "Set up Fast Clock" tool. But that exposes a bunch of other challenges:

- Do the various hardware fast-clocks support a "date"? There are probably a variety of options, with challenges to be resolved...

- Do the various JMRI features use a "real" date or a "fast-clock" date? Which date _do you_ want JMRI to support in the various cases? Should JMRI always use one type or the other? Or should JMRI provide away to choose? This would probably need to be addressd on a case-by-case basis.

- Are there any cases where JMRI might want to display both a "real-time" date and a "fast-clock" date? Again, this would probably need to be addressd on a case-by-case basis.

I just built and terminated a train. The date and time that is shown for me is the computer date and time

--
Peter Ulvestad
Linux Mint 22.1, JMRI 5.11.3plus, Java 21.0.5
JMRI Users Group Moderator ( /g/jmriusers )
JMRI Developers Group Moderator ( )
Tam Valley Group Moderator ( )
Sprog-DCC Group Moderator ( )
Edmonton Model Railroad Association ( )

On 2/21/2025 12:50 AM, Peter Ulvestad via groups.io wrote:

I just built and terminated a train. The date and time that is shown for me is the computer date and time

Dennis,

The guys helping with your initial question are some of the long-term "helpers" on this list. All my questions shown below apply to your situation, as well as to Peter, because "fast-clock" date information can be dealt with in a huge variey of ways within JMRI, so your answers are even more important than Peter's answers...

Peter,

Which JMRI "feature" do you use to "build" and "terminate" a train? I am clueless, since I have never "let" a computer decide what to do with "my" train...

Had you changed the "fast-clock"'s date "before" you built the train, using some not-obvious method? And did you "run" the "fast-time" clock at a rate different than 1:1? And run "long enough" to actually cause the date to change?

(It might even be important to "change" the fast clock's "date" _before_ starting whatever JMRI tool is used for building and terminating the train. JMRI coders may do odd things with respecy to date and time values, too. And it might be important if you use an extermal fast clock, especially an externally-controlled fast clock, so please disclose your . All of those details can really matter!)

If you did, then whatever mechanism you are using to "build" a train uses a "real-time" date mechanism. A JMRI "developer" would need to if/how that feature could/should make use of the fast clock.

If you did not modify the fast clock rate and run the clock to a new date, or set the fast clock "date" using some appropriate "trick", or if you figured some other, not-obvious-to-me way to change the fast clock's date, then you have not found out whether the JMRI mechanism which you used to "build" and "terminate" a train uses the "real-time" clock or the "fast-time" clock. That's because the JMRI "fast clock" automatically assumes the real-time "date", and only changes its date when the "fast clock" rolls-over from 11:59pm to 12:00am.

By the way, one can "see" the current "fast clock"'s "Date" with the following Jython script:

import jmri
timebase = jmri.InstanceManager.getDefault(jmri.Timebase)
print ("Current fast-clock date and time: " + str(timebase.getTime()))


When that Jython script has been run, it prints the current "fast clock" date and time:

Current fast-clock date and time: Sun Feb 23 03:34:35 EST 2025

On Fri, Feb 21, 2025 at 04:41 AM, billybob experimenter wrote:

Which JMRI "feature" do you use to "build" and "terminate" a train? I am
clueless, since I have never "let" a computer decide what to do with "my"
train...

Using the OperationsPro 'Train' window

Had you changed the "fast-clock"'s date "before" you built the train, using
some not-obvious method? And did you "run" the "fast-time" clock at a rate
different than 1:1? And run "long enough" to actually cause the date to
change?

There is no way that I know of to change the date of the fast clock that I know of. I don't believe the date is part of it.
I set the fast clock to 12-1, ran it for a few minutes, built and terminated a train, it still used the computer clock time.

--
Peter Ulvestad
Linux Mint 22.1, JMRI 5.11.3plus, Java 21.0.5
JMRI Users Group Moderator ( /g/jmriusers )
JMRI Developers Group Moderator ( )
Tam Valley Group Moderator ( )
Sprog-DCC Group Moderator ( )
Edmonton Model Railroad Association ( )

On 2/21/2025 7:36 AM, Peter Ulvestad via groups.io wrote:

There is no way that I know of to change the date of the fast clock that I know of.

That is consistant with my knowledge.

I don't believe the date is part of it.

It is part of the fast-clock "time", as shown by the Jythom code I provided.

I set the fast clock to 12-1, ran it for a few minutes, built and terminated a train, it still used the computer clock time.

Ok - the "OperationsPro"'s "Train" window looks at the "real-time" date, not the "fast-clock" date.

On Fri, Feb 21, 2025 at 05:39 AM, billybob experimenter wrote:

I don't believe the date is part of it.

It is part of the fast-clock "time", as shown by the Jython code I provided.

Yes, you are correct.
I now recall how this fast-clock "feature" affected a Saturday Operating session when it hit 2AM that happened to be the Sunday Daylight Savings time change.

--
Peter Ulvestad
Linux Mint 22.1, JMRI 5.11.3plus, Java 21.0.5
JMRI Users Group Moderator ( /g/jmriusers )
JMRI Developers Group Moderator ( )
Tam Valley Group Moderator ( )
Sprog-DCC Group Moderator ( )
Edmonton Model Railroad Association ( )

On 2/21/2025 8:43 AM, Dennis Coglianese via groups.io wrote:

It would be very helpful for me to see the actual date I terminated the train and any other action that gets logged to the status column.
At least one of you reported that you are getting the correct real time date.? The computer date and time is correct.

For someone who _never, ever_ runs any sort of computer-generated train movement, I _cannot_ help you much. Unfortunately, JMRI has never "cared" about the "fast date" concept. So noone ever bothers with it.

The JMRI "fast clock" _can_ keep track of it, at least in "incrementing the date portion when it rolls-over from one day to the next. And Peter had said that a "daylight savings time" change had affected his operating session. So the date can have an effect on JMRI.

But wWhether JMRI _does_ track the fast-date "correctly", in all the places that the "fast clock" is used is, however, not clear to me. And there are MANY things that come to mind that could be problematic.

And some "special cases" apply, like how some railroads did not honor the difference between "daylight savings time" and "Standard time". So crew members HAD to NOT change their pocketwatches, on those particular railroads, when Daylight Savings Time Began/Ended. Prototype railroads had a large number of ways to deal with the beginning and end of Daylight Savings Time". Does JMRI "model" this intentionally? Which one? Perhaps yes, perhaps no. But more likely, it can, for some JMRI configurations, in some parts of the program, but not in others...

On 2/21/2025 10:17 AM, Dennis Coglianese via groups.io wrote:

I change the time source to Internal Computer Clock from Loconet Fast Clock in an attempt to change the date, but it didn't make a difference.

There _could_ be something going on with respect to an external LocoNet Fastclock "master".

JMRI doesn't much care when a fast clock "date" changes - quite likely because the LocoNet "fast clock" was the first supported fast-clock.

LocoNet "fast clock" messaging can include a "day of the week" or possibly a "day of the month", but no LocoNet hardware I am familiar with allows the user to see or change that day number. LocoNet messaging does not give a "month number" or "year number". So why would JMRI's LocoNet fast clock code support the day, month or year? From what recall, JMRI just ignores the day-of-the-week or day-of-the-month data from a LocoNet fast clock message.

That _still_ doesn't answer your basic question. Someone who is familiar with the "OperationsPro" code and its "printouts" will likely have to "dig in" and figure out how your printouts sometimes use the current date and other times use an old date (but never the 1955 year you have specified)... It would not surprise me if the LocoNet external fast clock master has something to do with your problem.

On 2/21/2025 3:40 PM, Dan Boudreau via groups.io wrote:

setDate(Calendar.getInstance().getTime());
Where Calendar = java.util.Calendar

This probably uses the system's clock, not the JMRI "fast clock".

Not sure whether you _want_ to use the JMRI "fast clock"'s date, especially since it is difficult to "set" that date, though.