News for hackers. Stuff that matters.
Re:ISO-8601 date format reference not publicly available by pistolpeteDK on Tuesday March 09, 2021 @03:12PM (#26403520)
Yep - we needed the distinction for a scheduling/rota app. Some users had shifts that started at 24:00 and then ended sometime during the night. Other users had shifts that ended at 24:00. I know that it's common to use 23:59 in the latter case, but IMO that's just a poor workaround; and I'd argue that 16:00 -> 00:00 is a lot less obvious than 16:00 -> 24:00.

As for a shift that starts friday 24:00, you could argue that the shift is actually a 'Saturday 00:00 shift', but the users didn't see it that way; they are scheduling Friday nights shifts and want an extra person late Friday evening.

Re:ISO-8601 date format reference not publicly available by jcrawfordor on Tuesday March 09, 2021 @03:58PM (#26404147)
When I used to work in a 24/7 environment I would quip that "it's not tomorrow until the morning crew takes over." In a lot of practical situations I think it's easier for people to think about the early morning hours as being late the previous day. It tends to match shifts and reporting cycles better.
Re:ISO-8601 date format reference not publicly available by soneil on Tuesday March 09, 2021 @06:01PM (#26405648)
It's not tomorrow until I've been to sleep. It's not the morning until I've had a cup of coffee. Time is incredibly subjective. Clocks need to agree, but nomenclature does not.
Re:ISO-8601 date format reference not publicly available by Aloha on Thursday March 18, 2021 @11:40PM (#26509967)
It's not really morning until the sun comes up ;-)
Re:ISO-8601 date format reference not publicly available by EvanAnderson on Tuesday March 09, 2021 @06:25PM (#26405838)
I had a software project where I thought I could infer which shift was working from the time (because shift-related metrics were really important). I learned very quickly that shift and time, though related, are really separate data points.