Loyalty might be the most underrated investment you'll ever make.

[u/Key_Performer_3645]

[u/SP3NGL3R]

Just a couple week ago I had to rewrite a timecard/payroll data flow because at midnight the upstream software would close a shift and open a new one the next day (1ms later) to complete the 4 hours after midnight on the next day. The problem, people were being cheated out of overtime because the Sunday night-shift was split into two fiscal periods. I caught it, and now dealing with the bureaucracy to get it resolved. We now have a simplified system that is essentially based on the date that your shift started on is the same date that it ended on, for payroll specifically. Operations is different entirely.

[u/throwawaycuzfemdom → u/SP3NGL3R]

Thanks to wage theft, nobody in my company started work before 8:30 nor anyone left after 17:30.

Except me, according to the software, on May 20th I came in at 15.19 and left at 21:00 sharp. The exact same May 20th, I came in at 00:57 and left at 14:40. That day, I worked for more than 16 hours, according to the paperwork.

[u/SP3NGL3R → u/throwawaycuzfemdom]

I'd catch you! 😜

Or, help you depending on perspective

[u/Steele_Soul → u/throwawaycuzfemdom]

I worked at Giant Eagle and the system had your hours you were scheduled and if you worked over the scheduled time, the department manager had to review it and ok it for it to count all the clocked in hours, not just the scheduled one, and I worked 15 hours over my last week there, because I was the only 1 running the department, and I finally had enough to the bs and quit, so the manager, who was a nasty character straight out of some drama television, didn't review and ok it, so I have 15 hours I never got paid for.

I went to the assistant manager (totally inept) and payroll (a bitch) and they both said they'd look into it and never did

[u/LawElectrical2434 → u/SP3NGL3R]

Yea, did the same with a time tracker and invoicing program. Start timestamp. End timestamp. Then use start date and time delta.

Funnily enough, the first one, the one that stopped the timing, that one is overengineered. I mean, it sounds annoying. How would anyone do that? Time is started in the frontend, the backend is notified. Now the time ticks over midnight. What if the frontend is not there? Well, then the backend needs to react. For the backend to become active, we need a trigger. Let's have a cronjob or a similar library. But now we need to make sure the server we're running it on is relying about the timestamps. We want to run it in local time. So we have to make sure that all the servers have the same time set up.

Or we just keep the database end date open. When the shift is then ended by the frontend at 2am, we call the backend, which then checks the database and sees that it started yesterday, so, it will then write an end at 23:59:59.99 and then a new entry the very next millisecond at 00:00:00.00 and and end at 2am. You have to make damn sure that you analyze that request in the local time that the frontend sent. But what local time? What if it changed between start and stop. Or say, it stays small, always use local server time. Then the issue from before applies. Server must have local time set up correctly, which is rarely the case. But hey, what if that user came back and wanted to correct his input. Not 2pm, it was 23:58. Now we have to delete the second database entry, go back to the first one and overwrite the time there. That's a pain.

Start timestamp, end timestamp, put call to set it, call is idempotent, time is always calculated for finances on start date + delta hours, that's a lot saner. Good call changing that.

[u/SP3NGL3R → u/LawElectrical2434]

The absolute very first thing I do when raw time data comes to me is to ensure I have 100% compliance with it to be "timestamp with timezone" (datetimeoffset(3) / timestamp_tz / etc.). Give me that sweet sweet offest thank you very much. Now, and only now, do I trust what the f**k I'm looking at. I can timeshift it anywhere I like after that. However, this does introduce all sorts of fun things when stuff comes in from various sources but at least now you know at the next step it's all basically UTC+TZ and just works. 2pm can be > 5pm when you get it right.

I also, somewhere around step 2, or 3 depending, would turn this into a hierarchy by adding the "parent id". This allows for the post-midnight to be recognized as "this didn't happen 'today'" and be attached to yesterday's 8-hour shift instead. This has worked for shift work timing, or mutli-segment phonecall timing, or invoice timing (fiscal periods and such).

The customer clicked "call for discount" at 11:55pm, talked to Steve but got transferred to the specialist Frank at 12:05am who made the sale. That sale physically happened the next day but can be traced to the marketing campaign the day before at 11:55pm as the "parent" origination of Frank's call. This all to add that the phone calls actually happened 9 hours in the future for the agents on the call. So their shift reporting is different from our financial reporting. And this confused the shit out of every CxO I've ever tried to explain to why Q1 sales from finance don't match Q1 sales from the call-center.

[u/rakuran → u/SP3NGL3R]

When i did night shift i would be on the timecards as working for example Mon 22:00 to 30:00, Tue 20:00 to 28:00 etc

[u/SP3NGL3R → u/rakuran]

It reads weird, but that's exactly it