Community Edition 8.0.9 - Schedules corrupted

[ryang]

Hello,

About once a week or so, it seems my employee's upcoming schedules get corrupted. Typically, what happens is that the start time for each shift gets set to midnight. So for example, if I have an employee scheduled for 8am to 5pm, their schedule will suddenly become midnight to 5pm. If I have an employee schedule for noon to midnight, their shift will become midnight to midnight.

Is anyone else seeing this? It's very strange and very annoying, and confusing for my employees when I don't catch it.

Thank you.

[shaunw]

Are you using recurring schedules? Can you post a screenshot showing a few examples of the "corrupted" schedules?

[ryang]

I am using recurring schedules, but this has been happening since before I started using them.

I will have to wait until the issue occurs again to get a screenshot, as I've already corrected the schedules.

[ryang]

This is an example of what is happening:



The Wednesday and Thursday shifts both start at 17:00, not 0:00. The Friday shift starts at 08:00. The weekend shifts start at 12:00.

This keeps happening...

[shaunw]

If you Edit one of the corrupted scheduled shifts, can you post screenshots of that screen, as well as when you click on the "Audit" tab from there.

[ryang]

If you Edit one of the corrupted scheduled shifts, can you post screenshots of that screen, as well as when you click on the "Audit" tab from there.

The edit tab shows it incorrect. When I try to correct it, it says that the time overlaps with another scheduled shift, which is not true. The only way to correct it is to delete the shift and re-add. The audit tab doesn't show any changes. It's not anyone else. I'm the only one with admin rights on this installation, anyway, as I'm only using it for my team and trying to propose it company-wide.

Unfortunately, I have just deleted all of my custom schedules and switched them to recurring, since those don't seem to experience the issue. I'm really worried that this will bite me if I have to do any one-off scheduling, though.

I'll drop a few one-off schedules in for the next week or two and see if I can get the issue to bite again.

I'm using MySQL and I wonder if it has anything to do with that. I know it's not as strict on constraints as PostgreSQL, and I'm wondering if the code is putting an invalid date in somewhere that MySQL is converting to 0's, as it is want to do.

There's obviously a bug somewhere, regardless.

[ryang]

By the way, it's showing the employee as being absent yesterday. It's also showing him as being late today, even though he was 6 minutes early.

And yes, I've recalculated his time sheet...

[shaunw]

If you are using MySQL, it very well could be a timezone related issue, as MySQL doesn't technically have any knowledge of timezones when storing data. Its even possible it could just be general corruption in your MySQL tables, unfortunately we see that all the time with MySQL. MySQL accounts for less than about 5% of the TimeTrex install base yet about 95+% of the database related support requests.

We HIGHLY recommend against using MySQL whenever possible, and if you have more than about 25 employees or have employees in different timezones you absolutely should not use MySQL as it will completely fail you.

[ryang]

If you are using MySQL, it very well could be a timezone related issue, as MySQL doesn't technically have any knowledge of timezones when storing data. Its even possible it could just be general corruption in your MySQL tables, unfortunately we see that all the time with MySQL. MySQL accounts for less than about 5% of the TimeTrex install base yet about 95+% of the database related support requests.

We HIGHLY recommend against using MySQL whenever possible, and if you have more than about 25 employees or have employees in different timezones you absolutely should not use MySQL as it will completely fail you.

Is there a migration path to PostgreSQL?

[ryang]

If you are using MySQL, it very well could be a timezone related issue, as MySQL doesn't technically have any knowledge of timezones when storing data. Its even possible it could just be general corruption in your MySQL tables, unfortunately we see that all the time with MySQL. MySQL accounts for less than about 5% of the TimeTrex install base yet about 95+% of the database related support requests.

We HIGHLY recommend against using MySQL whenever possible, and if you have more than about 25 employees or have employees in different timezones you absolutely should not use MySQL as it will completely fail you.

I think this is more than timezone or DST issues...

[shaunw]

Is there a migration path to PostgreSQL?

Unfortunately there is no automated way to migrate between the two.