simulation that goes back in time

[Rafik Fainti]

Dear all,

I would like to ask you something about an odd, in my mind at least, behavior that I noticed while I was running a simulation.

Is it possible the value of t1 in a syncronization function to become less than the value of t0? If yes, why? I observed this behavior in the postsync function of the auction object while I was running a simulation.

Sincerely,

[David P. Chassin]

That is definitely not supposed to happen. Which version are you using?

[Rafik Fainti]

Dear Chassin,

I am using the "GridLAB-D 3.1.0-4882 (Hatwai) 32-bit WINDOWS RELEASE"

[David P. Chassin]

One question: when you say "t1 < t0", do you mean "abs(t1)<abs(t0)"? I ask because postsync returns a "soft" time, which is always negative and so numerically always less than t0, but should be interpreted as meaning "not mandatory for updating t0".

[Rafik Fainti]

I was trying to introduce data to a database and that's when I realized the problem. So I printed the values of t0,t1 in the postsync of auction object and I got this:

t0: 2000-10-29 02:59:00 PDT
t1: 2000-10-29 02:00:00 PST

[David P. Chassin]

Ahh! Different issue. Notice the change from daylight savings time to standard time. This is normal. You need to interpret the time correctly according to the timezone spec.

[Rafik Fainti]

Here is the code that I used to print them

gl_printtime(t0, timebuf, 127);
gl_printtime(t1, timebuf1, 127);
printf("t0: %s\n", timebuf);
printf("t1: %s\n", timebuf1);

[David P. Chassin]

You may want to use the raw value which is in seconds of the epoch. Most databases can handle this as it it equivalent to unix_timestamp (in mysql parlance). This will avoid the TZ issues completely.

[Rafik Fainti]

Thank you very much. You were very helpful.

One last, probably naive question. Why the timezone is changing?

[Rafik Fainti]

I've just found out why the timezone is changing. I am sorry for the silly question

Thank you very much again.