After the 2024.1.15 update, we’ve started noticing sporadic times when shop floor personnel clock in or job in/out via MES. Has anyone else noticed this? Sometimes there appears to be a rhyme or reason (+5 hours, +4 hours), but other times the offset is something else. This sometimes occurs within the same session (e.g. clock-in to shift via MES is right, then start activity is wrong). It’s almost like the requests are being sent to different servers in different time zones. Obviously, this will prove to be a pain for payroll and our production activities will have crazy durations during this period. Looking at the LaborHed table directly, all of the incorrect rows have all time related fields set to the wrong value, so I’m unsure if there’s a creative way to correct these in bulk. I’m open to suggestions
We opened and escalated an EpicCare case on Monday but have yet to hear from anyone.
Was there a change in .15 that requires some sort of config change I’m not aware of?
[edit]Or could this be some lingering effect of the Kinetic outage Sunday evening?[/edit]
I haven’t checked this in particular but we are experiencing wide ranging issues with timestamps throughout the system. Trying to figure out a pattern.
What’s worse is that we are seeing times for creating lots that are in the same minute of each other, two will be 5 hours off, and one will be correct.
This is going to be a major headache.
I would ask that others look around at their timestamps and see how wide ranging this is.
We’re still 100% classic MES. The offset is not reliable however, so if it is the difference between local and cloud, it’s bouncing between several timezones.
It’s a thought, but I believe we are pulling server time, and it’s not isolated to just us creating parts.
My silo reporting has half of them correct, the other is 5 hours off, and they are both being reported from the same server, and the same process/function.
I think they need to check the times on their app servers.
I just checked our silo reporting process, I am recording both the local time, and the server time, and one batch on both is 5 hours ahead, while the other is correct.
Edit: To be clear:
Silos 1-15 → Local time & Server Time Correct
Silos 16-27 → Local time & Server Time +5 hours
Reported from same server, approximately a minute from each other.
Is the clock in/out minute messed up the same way?
Clock in / out displayed times are redundant to LaborDtl ClockInMinute / ClockOutMinute, aka dateadd(minute, LaborDtl.ClockOutMinute, cast('19531030' as datetime)
… Unless your particular server records that at the server’s timezone instead of yours, in which case something like datediff(minute, '19531030', cast(getutcdate() AT TIME ZONE 'UTC' AT TIME ZONE 'Pacific Standard Time' as datetime)
We got the .15 update this past weekend and are seeing odd times in the system monitor. Reports are showing created 4 hours in the future (we are est) and some Last Actions are correct but not all.
Not sure how to tell the appserver. I’m part of the Cloud portal beta progam and only have access to a Start and Stop task agent button. (not for Live yet) No mention of any IDs.
I’m not seeing the same issue in Pilot or Addtional DBs so you may be onto something.
