Our methods of measuring time suck

[Plu]

Time is my number one annoyance in my job as a programmer because:

A) the whole way we measure it is terrible
B) most people barely understand the impact of time on data (and don't want to really think about it either)
C) it permeates through every part of your design and everyone just seems to kinda ignore it

Here's some silly mathematical examples to prove A.

Give me a simple to understand and mathematically supportable answer for these questions:
1) What date is "Januari 30th + 1 month"
2) What date is "Februari 28th - 1 month"
3) Using the two above rules, is Januari 30th + 1 month - 1 month still Januari 30th?


I'll leave examples and proof of B and C for later because they take a bit more time and I'm not going to bother if nobody cares :P
But really fellow IT people, the concept of time is kinda a big thing. Why is so little attention given to it?

[Atheon]

Give me a simple to understand and mathematically supportable answer for these questions:
1) What date is "Januari 30th + 1 month"
2) What date is "Februari 28th - 1 month"
3) Using the two above rules, is Januari 30th + 1 month - 1 month still Januari 30th?

You can't map the days of a 28-day month bijectively onto those of a 31-day month. You would have to understand the purpose for which the addition function is being used, and come up with a definition that works to fit it.

Does "+ 1 month" mean "+ 30 days"? Does "+ 1 month" mean "same date, but next month, with special cases for the 29th, 30th and 31st"? Or something else altogether.

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.

[Plu]

You can't map the days of a 28-day month bijectively onto those of a 31-day month.

Exactly.

You would have to understand the purpose for which the addition function is being used, and come up with a definition that works to fit it.

But you'll never be able to build something that makes sense in all situations, so you are constantly reinventing the wheel. And in order to come up with a definition that fits you first have to get your customer to think about what they want... good luck with that  :-&

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.

Yep. I've bumped into at least half of those so far and only played mindgames with the rest, but the final outcome is always something along the lines of #($^&@*$^#$ time systems. It's a fucking mess :(

[Jason78]

Time is my number one annoyance in my job as a programmer because:

A) the whole way we measure it is terrible
B) most people barely understand the impact of time on data (and don't want to really think about it either)
C) it permeates through every part of your design and everyone just seems to kinda ignore it

I agree with A.  I don't see you coming up with a better way though.

Most programmers don't get B either.  I've got a developer chap trying to wrap his head around timezones at the moment.   It's like watching a chimp trying to pilot a jumbo jet.

Sometimes C is true and sometimes it isn;t.

Here's some silly mathematical examples to prove A.


Give me a simple to understand and mathematically supportable answer for these questions:
1) What date is "Januari 30th + 1 month"
2) What date is "Februari 28th - 1 month"
3) Using the two above rules, is Januari 30th + 1 month - 1 month still Januari 30th?

1) 20140130 + 1 month = 20140228
2) 20140228 - 1 month = 20140128
3) The way you've written it?  Yes.

I'll leave examples and proof of B and C for later because they take a bit more time and I'm not going to bother if nobody cares :P
But really fellow IT people, the concept of time is kinda a big thing. Why is so little attention given to it?

Huge amounts of attention are given to it!   Who exactly is teaching you to write code?

[Plu]

I agree with A. I don't see you coming up with a better way though.

I have some ideas, but it'll be hard to convince billions of people to change the way they handle time :(
But still something I want to raise awareness on. The main problem though isn't that the current system is bad (which it is) but that most people aren't aware of this, so I want to start there.

1) 20140130 + 1 month = 20140228
2) 20140228 - 1 month = 20140128
3) The way you've written it? Yes.

These are not consistent rules. If 1) and 2) hold, 3) either does not or only does in very specific situations. Or it's only going to work if you execute them immediately after another and will fail if you convert them between systems and then do the second calculation later. (hey look, delaying the execution could change the outcome? something something time in programming.)

Who exactly is teaching you to write code?

The internet :P

I understand the basic idea of datetimes and timezones (most implementations are... passable) but I run into far more problems when you go beyond that and look at things like changing data, delayed execution, composite values, and the like... many of which have their basics within the concept of time passing although a bit more low level. And we just keep bumping into them with all the web applications we build, and it's barely getting better even though a change in approach could probably solve a whole lot.

And the other people in my office had never heard of the idea of a temporal database and don't really seem interested even though it would solve so many problems we have in our software. And it's like one of the better ideas I've heard as far as databases are concerned.

(Also part of this topic is just me being annoyed at constantly running into the same shit, so take it with a bit of salt at times)

[Jason78]

I have some ideas, but it'll be hard to convince billions of people to change the way they handle time :(
But still something I want to raise awareness on. The main problem though isn't that the current system is bad (which it is) but that most people aren't aware of this, so I want to start there.

What are your ideas?  You wouldn't be the first to be frustrated with the current way we mark time, it would be interesting to see how your ideas are different.

1) 20140130 + 1 month = 20140228
2) 20140228 - 1 month = 20140128
3) The way you've written it? Yes.

These are not consistent rules. If 1) and 2) hold, 3) either does not or only does in very specific situations. Or it's only going to work if you execute them immediately after another and will fail if you convert them between systems and then do the second calculation later. (hey look, delaying the execution could change the outcome? something something time in programming.)

That's why 3) had the caveat "The way you've written it?".   Changing the way you do the calculation will change the answer.  However the outcome is consistent and predictable.  

Who exactly is teaching you to write code?

The internet :P

There's your problem.  Right there.  In bold.

[stromboli]

You guys are all talking about IT shit and I haven't figured out time zones yet.  :-k

[Atheon]

And in order to come up with a definition that fits you first have to get your customer to think about what they want... good luck with that  :-&

That's the crux of the problem: what the time function is going to be used for. 9 times out of 10, it has to do with accounting. That means talking to someone in their Accounting Department. :)

[Plu]

What are your ideas?

I'll try putting them to paper later today.

Changing the way you do the calculation will change the answer. However the outcome is consistent and predictable.

If changing the way you do the same calculation might change the answer, I don't really consider it predictable, but maybe that's me...

There's your problem. Right there. In bold.

It's probably part of the problem, yeah ;)  Have any better suggestions that don't involve taking out a student loan? I can probably convince my employer to get some more books. We really need more in-depth knowledge on programming here.

That's the crux of the problem: what the time function is going to be used for. 9 times out of 10, it has to do with accounting.

We're building an application that allows you to plan events, along with planning people to work shifts, managing those workers' vacations and availability, and then checking them in and out when they show up and in the end paying them for hours worked... handling time is all this application does and we're still running into problems.

I'm just really glad they let me build the tracker for when people are still available for work... their idea was to just loop over every 15 minutes of every day of the month and calculate whether or not the person was available to work at that point  8-[

[Jason78]

What are your ideas?

I'll try putting them to paper later today.

Awesome!  I can't wait to hear them.

Changing the way you do the calculation will change the answer. However the outcome is consistent and predictable.

If changing the way you do the same calculation might change the answer, I don't really consider it predictable, but maybe that's me...

Consider the case of calculating a number to an arbitrary precision.   How you decide to do it, and what kind of variable you'll be using for storage will have an effect on the final answer.

The trick is to be consistent with your method.  If you're going to calculate net changes before applying them to your stored date, then do that every time you calculate dates.

There's your problem. Right there. In bold.

It's probably part of the problem, yeah ;)  Have any better suggestions that don't involve taking out a student loan? I can probably convince my employer to get some more books. We really need more in-depth knowledge on programming here.

There are plenty of courses your employer could pay to send you on.   Book learning is great, don't get me wrong.  But there are times when you need an actual teacher that can spot your mistakes and set you on the right track.  

Though getting your employer to realise that formal training saves them money is an entirely different problem.

That's the crux of the problem: what the time function is going to be used for. 9 times out of 10, it has to do with accounting.

We're building an application that allows you to plan events, along with planning people to work shifts, managing those workers' vacations and availability, and then checking them in and out when they show up and in the end paying them for hours worked... handling time is all this application does and we're still running into problems.

I'll give you three guesses as to what the application I'm maintaining at the moment does...

[PopeyesPappy]

Our methods for measuring time are incredibly accurate. There are now clocks that are accurate to 0.000000000000000001 of a second. That's an error rate of one second in something like 30 billion years. It is our method of expressing time that you are having a problem with.

[Plu]

Consider the case of calculating a number to an arbitrary precision. How you decide to do it, and what kind of variable you'll be using for storage will have an effect on the final answer.

The trick is to be consistent with your method. If you're going to calculate net changes before applying them to your stored date, then do that every time you calculate dates.

I dunno. Intuition says that technically by deciding to store the arbitrary precision number itself you're already approaching it wrong.. you should be storing the calculation itself, which shouldn't really contain any arbitrary position numbers. (And if it does, those are probably also better stored as calculations. If you start doing that, arbitrary position will start disappearing from your data pretty quickly, except in the form of fleeting variables where it shouldn't matter that things are rounded.)

(Of course I understand the performance issues of this approach might be very scary, so I can understand that it generally isn't applied as such.)

I'll give you three guesses as to what the application I'm maintaining at the moment does...

If you're doing the same kind of thing, can you give me a short breakdown of how you'd draw a calendar that is one color if the person is available and another if the person is not available, with the knowledge that someone's availability can depend on their base contract hours, exceptions to it because they decided to work tomorrow instead of today, inavailability because they requested a day off, as well as not being available because they've already been scheduled?
I'm just curious to see if my approach is a good one, because it's using a sort of algorithm that I've made up myself and doesn't really seem to exist in the wild; at least I was unable to find anything resembling it. (But it might just be because I don't know the search term.)

(Of course the above deviates a little from the original topic, but I'm still interested in your approach :P)

[Jason78]

Consider the case of calculating a number to an arbitrary precision. How you decide to do it, and what kind of variable you'll be using for storage will have an effect on the final answer.

The trick is to be consistent with your method. If you're going to calculate net changes before applying them to your stored date, then do that every time you calculate dates.

I dunno. Intuition says that technically by deciding to store the arbitrary precision number itself you're already approaching it wrong.. you should be storing the calculation itself, which shouldn't really contain any arbitrary position numbers. (And if it does, those are probably also better stored as calculations. If you start doing that, arbitrary position will start disappearing from your data pretty quickly, except in the form of fleeting variables where it shouldn't matter that things are rounded.)

(Of course I understand the performance issues of this approach might be very scary, so I can understand that it generally isn't applied as such.)

How would you store the fraction 1/97?  Would you seriously store it as a calculation rather than store it as what it is?  

Here's a hint: eventually you are actually going to have to do that calculation in order to present the result.   Depending on the language you're using, you'll probably only be able to use about 16 digits out of the 96 that calculation produces.

Mind you, it all depends on what you're trying to achieve.  

I'll give you three guesses as to what the application I'm maintaining at the moment does...

If you're doing the same kind of thing, can you give me a short breakdown of how you'd draw a calendar that is one color if the person is available and another if the person is not available, with the knowledge that someone's availability can depend on their base contract hours, exceptions to it because they decided to work tomorrow instead of today, inavailability because they requested a day off, as well as not being available because they've already been scheduled?
I'm just curious to see if my approach is a good one, because it's using a sort of algorithm that I've made up myself and doesn't really seem to exist in the wild; at least I was unable to find anything resembling it. (But it might just be because I don't know the search term.)

(Of course the above deviates a little from the original topic, but I'm still interested in your approach :P)

Why do I feel like I'm doing someone else's homework for them? :D

Sounds to me like you already have a breakdown of how you'd draw a calendar to show availability.   What I would do is look at their audit data, and what they have scheduled along with business logic rules that govern how an employee can be available  (for example, the maximum number of hours a person can be asked to work in a given week varies from country to country).  

You've essentially got 3 things to consider:

1)  What has the employee done already?   We colour these bits in.
2)  What has the employee been scheduled to do?  We colour these bits in too.
3)  What arbitrary restrictions can be applied?  ( Working Time Directive, contract terms, etc)  And we colour in these bits as well.   Anything left uncoloured after now means the employee is available. :)


Here's a good question for you:

You have an employee with two recurring schedules.  Schedule 1 repeats every X number of days, and Schedule 2 repeats every Y number of days.

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

[AllPurposeAtheist]

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

[Plu]

How would you store the fraction 1/97?

Step one is asking why you want to store the fraction 1/97. If it's somehow relevant data that's mapping something important in the real world, I would seriously consider mapping it exactly. That means either at perfect precision (if it's 96 digits long that can be done) or just as the calculation 1/97 if it's an infinite sequence. Of course this requires that it's actually relevant to know all these digits.

Mind you, it all depends on what you're trying to achieve.

So yeah, this :P

Why do I feel like I'm doing someone else's homework for them?

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.

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.

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.