Our methods of measuring time suck

[Jason78]

Step one is asking why you want to store the fraction 1/97.

I wish more programmers would approach requirements this way!  That is entirely the right question to be asking.

I actually have the whole thing running in a live enviroment already, I was just curious if I'd done it right ;) There's a big difference between code that works and code that's good.

I totally agree.   Far too many programmers will implement a solution that works, rather than implement one that works well.  Even worse, I've seen programmers fail to research their problem properly and try to re-invent a solution that's already been tried and tested.  You tend to see a lot of this in date and time calculations (sorry to bring us back on topic).   What usually ends up happening is that the solution is good for general cases, yet fails on special cases (such as leap years).

My current implementation (on a technical level) takes a list of all the elements that can impact a person's availability and a starting point, and from that point starts asking each item in the list for the next time it's going to change its opinion, and uses these opinions to determine each point where availability has to change from available to not available. It seems to work quite well on a algorithmic level but I could not find any descriptions of this kind of system anywhere, so I have no idea if it's a common pattern, or if there's something better available. It handles things like people who have multiple roster exceptions on the same point very easily.

Sounds good to me.  Scheduling is one of those problems that can be as fine grained as it needs to be.  Ultimately, the acid test is "Is the system able to answer the questions I pose it?".  (The way we do this is to identify specific use and abuse cases and construct unit tests to confirm that the system does what we expect it to, but now I'm rambling...)

You're quite right to ask yourself "is something better available?", or "is this the most efficient way of doing this?".  The reason for this is that just because a solution works, doesn't necessarily mean that it will scale.  

What is an efficient way of telling when (or indeed if) those two schedules will collide?

Depends on what you mean with collision (and efficient), but if it's two repeating rosters the easiest way would be to map them out to the least common multiple of X and Y and start looking for overlaps.

Correct.   And the easiest and most efficient way I've found of doing that is using the Extended Euclidean algorithm

[Jason78]

I've always wondered why there isn't such a thing as a metric clock at least for daily values. I know the 28/30 day cycles, etc., but why not just change to 100 distinctive time zones drawn straight up and down on a map, not following rivers, borders, etc., and 100 minutes in every hour and 100 seconds in a minute. I'm not suggesting changing every clock and watch, just use it for practical things like sciences, programming,  etc..It would damn sure simplify things especially those STUPID math questions in school about the train traveling west 500 mile per and grandma walking east at 1 mph.. #-o

Because people are awkward.


If you're working in the sciences, then you ought to be using SI units and using seconds as your measure.

[Plu]

The even worse acid test is "Is the system able to answer the questions I'll have to pose it next week?".

But I'm not sure how the Extended Euclidean Algorithm works with two spreads of numbers, it seems to work only on single numbers? I'm not sure how you'd apply this if I want to do the test for a whole spread of numbers. (Other than "by checking each numbers in the spread one at a time", which requires there to be limited precision in there)

(Also my algorithm right now allows perfect precision scheduling. Not that these guys really care, it's more of a free side effect, but you could schedule people in microsecond periods if you wanted to :P)

[Jason78]

The even worse acid test is "Is the system able to answer the questions I'll have to pose it next week?".

Why would the questions you pose it from one week to the next be any different?  (unless of course the requirements change, but then, you can't code for what you don't know about)

But I'm not sure how the Extended Euclidean Algorithm works with two spreads of numbers, it seems to work only on single numbers? I'm not sure how you'd apply this if I want to do the test for a whole spread of numbers. (Other than "by checking each numbers in the spread one at a time", which requires there to be limited precision in there)

You don't need to test for a whole spread of numbers.   If a cleaner is scheduled to clean Company A once every 3 days, and is scheduled to clean Company B once every 4 days, then with both cycles starting from day 1 that algorithm will show you that on day 12, that cleaner will have to be in two places at once.

(Also my algorithm right now allows perfect precision scheduling. Not that these guys really care, it's more of a free side effect, but you could schedule people in microsecond periods if you wanted to :P)

Well you never know when stuff like that might come in useful :D  I don't want to go into too much detail, but between phone calls and time and attendance data, half a second has been able to show us that a person was breaking a specific rule.

(I'd love to go into more detail, but for obvious reasons, I can't)

[Solitary]

I'm still trying to figure out what time it is at the North Pole.  :shock:  :-k  #-o  :-?   Solitary

[Plu]

You don't need to test for a whole spread of numbers. If a cleaner is scheduled to clean Company A once every 3 days, and is scheduled to clean Company B once every 4 days, then with both cycles starting from day 1 that algorithm will show you that on day 12, that cleaner will have to be in two places at once.

That assumes that your unit is a whole day in both situations. What if you schedule the cleaner to work 15 minutes a week in one place and 3 minutes a week in another, and start measuring from there? You'll get a much harder kind of collision there, where he could overlap in many points. (Although technically even then you could start measuring each of the 15 minutes because the common ground between the two is still relatively close.)

But it's still a useful algorithm to have :) Will keep in mind for other situations.

As for time at the North Pole... add it to reasons timekeeping is weird :P

[Solitary]

A man has a plane and starts off at 8 O'clock AM in the morning of Monday March 18 and  flies West following his shadow below him. He comes back to where he started and arrives at 8 O'clock AM Tuesday March 19. When did it become Tuesday March 19?  :shock:    Solitary

[Jason78]

A man has a plane and starts off at 8 O'clock AM in the morning of Monday March 18 and  flies West following his shadow below him. He comes back to where he started and arrives at 8 O'clock AM Tuesday March 19. When did it become Tuesday March 19?  :shock:    Solitary

Midnight.  At precisely 00:00.

[Solitary]

A man has a plane and starts off at 8 O'clock AM in the morning of Monday March 18 and  flies West following his shadow below him. He comes back to where he started and arrives at 8 O'clock AM Tuesday March 19. When did it become Tuesday March 19?  :shock:    Solitary

Midnight.  At precisely 00:00.

On who's clock and location?  :P   Solitary

[Jason78]

A man has a plane and starts off at 8 O'clock AM in the morning of Monday March 18 and  flies West following his shadow below him. He comes back to where he started and arrives at 8 O'clock AM Tuesday March 19. When did it become Tuesday March 19?  :shock:    Solitary

Midnight.  At precisely 00:00.

On who's clock and location?  :P   Solitary

On any clock in any location, the day starts at 00:00.

[AtheistMoFo]

A man has a plane and starts off at 8 O'clock AM in the morning of Monday March 18 and  flies West following his shadow below him. He comes back to where he started and arrives at 8 O'clock AM Tuesday March 19. When did it become Tuesday March 19?

Tuesday for him would start at the point where and when he crosses the international dateline.

[BarkAtTheMoon]

Time is a big problem for programmers for many reasons: time zones, daylight savings, historic changes of time zones/DSL zones, Julian vs. Gregorian calendars (if looking at events centuries past), calendars of other cultures, leap years, leap seconds, etc. etc. etc.

On top of that, most languages I've used have shit for date functions and most data sources have shit for date formats. I currently have to deal with dates of the format "913" for September 2013, "1013" for October 2013 in a primary datasource. I seem to remember this y2k thing where that kind of shit was supposed to be dealt with.

[Jason78]

The .net DateTime object handles all of that.