Clock in GDC-TMS didn't switch to daylight saving time

[Peter Mork]

See screen capture. The Scheduler screen has not updated for the one-hour shift. How do I do this?

Thanks.

[Bruce Cloutier]

The Clock, Date, Time and Timezones was the biggest pain in the ass in developing the JNIOR operating system. Having written all of that I can tell you that none of it is straight forward. So it is amazing that any of this DST stuff goes smoothly anywhere. I eventually had to create a custom timezone capability inclusive of DST rules to get everyone covered.

Is the GDC-TMS Linux based? Didn't they use a Rasp-Pi in something?

[Peter Mork]

Running Windows 10.

[Carsten Kurz]

Has the underlying windows switched already?

[Peter Mork]

Yes, everything switched save the TMS.

[Mark Gulbrandsen]

The Clock, Date, Time and Timezones was the biggest pain in the ass in developing the JNIOR operating system. Having written all of that I can tell you that none of it is straight forward. So it is amazing that any of this DST stuff goes smoothly anywhere. I eventually had to create a custom timezone capability inclusive of DST rules to get everyone covered.

Is the GDC-TMS Linux based? Didn't they use a Rasp-Pi in something?

Yes, it runs on Linux... And the Pi is used in the SR-1000 and up IB servers. Not sure which Pi though. I keep forgetting to ask them...

[Mark Gulbrandsen]

I have to assume you do have internet hooked to it and that you are using NTP to update the servers to the TMS??? Might also be your on-board battery located on the motherboard. When that lets low or dies then the time will not update.

[Mark Gulbrandsen]

See screen capture. The Scheduler screen has not updated for the one-hour shift. How do I do this?

Thanks.

In the search box or magnify glass type in Time and then you can do various settings on that page. Be sure set time is unchecked, in fact you may find that turned off... and then set the time in the pop up box. Turn the Auto set back on. Then sync the time. After time syncs you should get a green check mark next to that box. If you don't get it then something is wrong, possibly with your network.

[Peter Mork]

Tried resynching time, although it reads correctly on my Windows screen. Did not affect the TMS however. Also rebooted the system and reopened TMS, but it diddn't correct itself.

Actually, the situation is weirder than I thought - I was mistaken when I said it failed to update; actually it moved two hours forward, instead of one ("Spring forward", right?).

On the TMS, that displays as a broken red vertical line in the Scheduler screen (clock icon at the bottom) - this line moves from left to right as the time progresses - it's currently showing time as18:14, when it should be 17:14. See new screen capture.

Overall, since the TMS exists as a program in Windows 10, it should conform to what time Windows says it is. But ti doesn't.

1814.jpg

[Steve Guttag]

This is a known glitch. Note, the time line is actually 1-hour in advance of DST (so it moved 2-hours). I'm told by tech support that it will be correct tomorrow. It is a visual issue only. The shows should run at the correct time and the shows, as they appear in the schedule on the TMS should appear at the correct time.

[Peter Mork]

Thanks. "Correct tomorrow", eh? We'll see about that.
I get that it doesn't affect the actual running of the shows (which were all programmed in two days ago, and are controlled at the projectors), but it bugged me - hope it rights itself.

[Bruce Cloutier]

The high quality programming we come to expect in the 21st Century.

[Steve Guttag]

I'm sure some things are slower to be caught. DST sorts of things only affect people 2-days out of the year.

[Steve Guttag]

As predicted, the timeline is correct today.

[Bruce Cloutier]

So it is only a bug twice a year for a total of 2 days. Odds on it being fixed? Someone should consider the cost in having a couple of dozen panicked customers twice annually.

The way of it though is that programmers rely on libraries not knowing the least as to who wrote them and whether or not they have quirks like this. Regardless, testing usually involves a few minutes and declaring that it works. Support eventually recognizes that it is a bug. In this case the recommendation is just to wait for tomorrow and that your shows will still fire off on time. Unfortunately this one won't be resolved by a reboot. So then the customer goes away and support records the event as resolved. The developers pay attention to things that aren't resolved and where customers are likely to follow up with concern and sales might be impacted. That is assuming that there are any developers still assigned to this product. Generally they are all busy with the next product expecting that everyone trash the one they have and drop more coin on the latest and greatest set of bugs.

Even a small thing like this bug would lead us to lose sleep here.

You know after 40+ years of computing... the clock, time and date should all be pretty well understood and well-implemented. DST is handled inconsistently. Do Windows file times still all shift by an hour when DST starts/ends? I seem to remember that they stored the creation times and last modification times in local time and displayed those according to the current DST status and not whether or not it was DST when the file was created/changed. JANOS goes out of its way not to do that.

Of course, the simple act of printing is no longer straight forward. Lately Windows has been randomly changing the default printers on us. I print and then go on a search to see where it came out. And the rule now is more !WSIWYG. To get something presentable generally it takes another try. After all this time this basic task should actually be simple and reliable. Instead it is almost getting worse by the day.

Is Windows the proper choice for a product like this? Like I've said I have production equipment running on Windows 10 and to insure uninterrupted production these machines have to remain disconnected from the network (BSG-esc).

For what these folks invest in these systems (again and again) there shouldn't be any low priority bug.

I'm just saying... I could be wrong. ;-)