View previous topic | View next topic

Hours in a day

Page 2 of 4
Goto page Previous  1, 2, 3, 4  Next

pedxing
757757.  Thu Nov 04, 2010 2:16 pm Reply with quote

Quote:
I have literally no idea what this means.


I'm sorry that wasn't clear. Let me try again.

Where the team working the shift actually is located is immaterial to the program when it comes to scheduling the shift. They could be in Denver, in London, or as many of the teams are, scattered around the world.

What I was trying to describe is that the UTC offset of their shift start and stop times follows the UTC changes of Denver, not of the place that they are living. Londoners work a 7 or 7.5 or 8 hour shift on March 13, 2011 by leaving an hour earlier and possibly starting some amount of time earlier as well, and the next day they come in to work an hour earlier. Then on March 27, 2011 their shift starts an hour later.

So you can't take the start time of the shift in London as a static point of reference and work backwards from there. The start time in London is driven by the time in Denver, not the other way around. I hope that is clearer.

Quote:
There's your problem, then. If you're writing a piece of code designed to deal with working shifts across different time zones, then it absolutely has to know something about local time in those different time zones.


No. You are misunderstanding the problem. This is my fault for giving a detail to try to head off an argument of the type "Don't schedule shifts for 2:30AM". I included the fact that in this specific instance it was a London team only to explain why it started at 2:30AM.

Let's change the story. Now it is a team of bakers in Denver who all start work at 2:30AM. To the software there is no difference between these two scenarios.

And if you think I get to tell this customer when they get to schedule shifts, you have an exaggerated view of my importance. I couldn't even get them to run their server in UTC (if they had all these problems disappear and the system schedules shifts exactly as it is supposed to do).

Whatever the reason that a customer wants to do this, whether it is bakers or Londoners or the time the last bus runs to the plant or something else altogether, chances are the customer has a good business reason for it and neither you nor I get any say in the matter.

Quote:
That depends entirely on the application, and is something that needs to be established at the planning stage.


It does depend on the situation, you are right, that is what I have been saying all along. There is no one right answer.

But you are wrong to say that it depends on the application. And it is not determinable at the planning stage.

For example, you want to use duration to add up the hours that people work. Fair enough. Now on the same report, you are asked to add a bar graph on a timeline that shows when they worked. Should be simple, you have the raw data. Only when you draw the graph you have to change over to start/stop time instead to make the bars come out the right length. So your careful planning failed to deal with the realities of incremental software development.

Quote:
I would begin by sitting them down and explaining how the 1:30 job will run twice every March, and the 2:30 job will not run for one day in October.


You are still not understanding the situation. I am not doing the equivalent of configuring cron on a client's computer. I am writing the equivalent of the cron program. Anything I change changes for everyone that runs the program.

Why don't the authors of the cron program change the way it works so that it deals with DST changes? Because there is no one right answer. They instead opt for a solution that is almost never correct, the same one you designed into your "system", the Pirates of Penzance approach where you simply don't run the job set up for the imaginary time.

Like the developers of cron, I can't stop people from setting up shifts between 1:00AM and 3:00AM. The trouble is that I'm the one that gets blamed if shifts aren't set up the way that a customer expects. I would certainly never take the approach you suggest and that cron implements, btw. If a customer suddenly had no one show up for a work shift, I'd be fired and rightly so.

When the software doesn't work as expected, it doesn't help that I told them to run their server in UTC. The customer will still hold me in "contempt" because I don't know how to deal with such a "well-understood problem", will still lecture me about "the six P's" and all the "open source libraries that solve this problem", will still threaten to drop their maintenance agreement (thus costing the company significant revenue) unless I get to the office at 3AM and work straight through until this "obvious" bug is solved.

The trouble is that the customer has a little knowledge, but they don't have enough to realize how little they actually know about what is really a very complicated issue.

Quote:
Again, I'm not sure of where you're living.


Victoria, British Columbia. I was quoting the sunrise/sunset times for when we have our DST change on November 7th.

It really doesn't matter though. I don't believe there is a right answer as to whether people want more light in the morning or the evening during the winter, it is all a matter of preference. And that's the trouble. For the price we pay (with almost no-one realizing the cost) to have more light in the morning, it is expensive to give that benefit to the subset of people that want it.

But that's just my humble opinion.

Quote:
Because, of course, nobody would ever get confused by changing their working hours throughout the year, would they?


Well, no, they don't.

This is one of the more common scenarios for how the global companies that run my software schedule shifts. They will often have "follow-the-sun" scheduling, where responsibility for a task is covered 24 hours a day by having shifts in different locations around the world work their ordinary day shifts. In order to ensure continuous coverage, they do not have the local DST changes alter the UTC time that the shifts start and end.

So you might have a team in Los Angeles, another in London, and a third in Perth. The LA team would work UTC-8 regardless of DST changes. The London team would work UTC regardless of DST changes. The Perth team would work UTC+8 regardless of DST changes. All teams will work 9:00 to 5:00 part of the year, and 8:00 to 4:00 the other part.

So far, no one has gotten confused.

Quote:
And think of all those poor computer programmers.


As I say, my software already does this. As someone who has worked both sides of the problem, I can tell you that this is the easy part of the program. Compared to the DST changes with imaginary and duplicated times, it causes no problems at all.


Last edited by pedxing on Fri Nov 05, 2010 10:51 am; edited 1 time in total

 
suze
757801.  Thu Nov 04, 2010 5:39 pm Reply with quote

pedxing wrote:
Victoria, British Columbia. I was quoting the sunrise/sunset times for when we have our DST change on November 7th.


Allow me to come off topic for a moment and welcome a fellow British Columbian to these forums. Hello, fellow British Columbian!

I'm from Vancouver, although I've lived in England for the last twelve years.

 
nitwit02
757827.  Thu Nov 04, 2010 9:01 pm Reply with quote

Hi Pedxing - greetings from Alberta.

 
monzac
757854.  Fri Nov 05, 2010 4:13 am Reply with quote

... and g'day from Melbourne :)

 
'yorz
758011.  Fri Nov 05, 2010 3:49 pm Reply with quote

And greetings from Haltwhistle, too :)
(Darkest Northumberland)

Edit: On a lighter note (see what I did there), I read somewhere that a BIG bonus for longer daylight would be to accommodate the MANY people who can now go out after work and EXERCISE.
Somehow I doubt that.

 
pedxing
758052.  Fri Nov 05, 2010 7:45 pm Reply with quote

Hello to all.

And to suze, I'll just add that I was born and raised in Vancouver, and only came to Vancouver Island 9 years ago. Your relocation was clearly much more ambitious.

 
suze
758060.  Fri Nov 05, 2010 8:26 pm Reply with quote

I too was born and raised in Vancouver (East Side, what with being a Polish Canadian). After spending far too many years at UBC (I went as far as PhD) I needed to find a job, and the first job I found was in Red Deer, Alberta.

I can't say that the prospect of spending my life there filled me with joy - it's not a city that is exactly full of people who wear nose rings and vote NDP! So I looked for a different job and eventually found one in London, England.

When I first came to England I wasn't sure how long I'd be staying - but then I met a guy. We got married and by now I'm a British citizen, so it looks like I'm staying for good!

 
pedxing
758232.  Sat Nov 06, 2010 3:14 pm Reply with quote

Interesting. I worked at UBC for 10 years, mostly on a research project applying artificial intelligence technology to the law.

 
suze
758254.  Sat Nov 06, 2010 5:23 pm Reply with quote

Then chances would have to be that at some point we were on the campus at the same time.

As British readers mightn't know, UBC is a large campus - nearly two miles from one end to the other - and if Law is where I think it is, it and Linguistics are almost at opposite ends of it. Accordingly, we may never actually have met - but we just proved that it's a small world, all the same!

 
'yorz
758271.  Sat Nov 06, 2010 6:58 pm Reply with quote

You may have met but not exchanged names?

 
Leith
758310.  Sat Nov 06, 2010 9:31 pm Reply with quote

Welcome Pedxing

Sounds like an unenviable project you're working on.

It could perhaps be worse - you could be working with times and dates for historians:
QuirksMode.org: Making <time> safe for historians

If the reports I've read are correct, I've rather less sympathy for the Apple developers. They weren't writing a complex bespoke application and are unlikely to have been prevented from using UTC times when they needed to. They were writing a dedicated clock app for a mass market product and managed to get the recurring alarm times wrong. That seems like a fairly serious QA lapse to me.

Other interesting time-related issues crop up in spacecraft avionics. GPS satellite orbits are such that time passes noticeably faster on-board the satellites than it does on the ground. The satellites have to adjust their clock rates in order to keep in step with ground station clocks:
http://www.astronomy.ohio-state.edu/~pogge/Ast162/Unit5/gps.html

On a similar topic, here are some musings from an ISS astronaut on time dilation and other aspects of relativity:
http://spaceflight.nasa.gov/station/crew/exp7/luletters/lu_letter13.html

 
dr.bob
758964.  Tue Nov 09, 2010 6:57 am Reply with quote

pedxing wrote:
Let's change the story. Now it is a team of bakers in Denver who all start work at 2:30AM. To the software there is no difference between these two scenarios.

And if you think I get to tell this customer when they get to schedule shifts, you have an exaggerated view of my importance.


Erm, I never suggested you get to tell your customer what to do. You seem to have misread my post when I said:
Quote:
I would begin by sitting them down and explaining how [...] the 2:30 job will not run for one day in October. Then ask them how they want to deal with that situation.


If the client wants to perform something at a time of day that doesn't exist, then it's not possible. To quote a famous Canadian, "Ye cannae change the laws of Physics, cap'n!" Therefore it is necessary to ask the client how they want to tackle this problem.

This will largely depend on the situation. For instance, for a team of bakers I would imagine it's important that they start work a certain number of hours before the customers arrive, so they have time to bake all the bread-related products they need to produce. Thus, a baker will probably decide to start the shift at 1:30 instead. However, to a late-night security guard, say, it might be more important that he takes over from the previous shift a certain number of hours after that previous shift started, so he might have his shift scheduled to start at 3:30.

Either way, it's for the client to be educated in the fact that this is a problem and then asked to decide.

pedxing wrote:
I couldn't even get them to run their server in UTC


Why would you need them to run their server in UTC? You know what timezone the server is running, so just convert to UTC before you start.

pedxing wrote:
It does depend on the situation, you are right, that is what I have been saying all along. There is no one right answer.


There is no one general right answer, but for each individual situation there is most definitely a right answer and a wrong answer.

If a bakery opens at 7:30am and needs 5 hours to bake all their bread, then starting shifts at 3:30 on spring forward day is clearly a very wrong answer.

pedxing wrote:
Like the developers of cron, I can't stop people from setting up shifts between 1:00AM and 3:00AM. The trouble is that I'm the one that gets blamed if shifts aren't set up the way that a customer expects.


Clients invariably assume that programmers have finely tuned powers of telepathy and can predict what the client needs without the client having to specifically tell them. Disabusing clients of this notion is the only way to stay sane :)

pedxing wrote:
So you might have a team in Los Angeles, another in London, and a third in Perth. The LA team would work UTC-8 regardless of DST changes. The London team would work UTC regardless of DST changes. The Perth team would work UTC+8 regardless of DST changes. All teams will work 9:00 to 5:00 part of the year, and 8:00 to 4:00 the other part.

So far, no one has gotten confused.


I find that remarkably hard to believe. That would be a bit like me claiming that nobody ever forgets to change their clocks when DST starts and ends up coming in to work an hour late. People are human and make mistakes. People get confused by DST, so I'm fairly sure that some people must've been confused at some point by the shift patterns you describe.

I find your suggestion of simply changing work patterns interesting, though I can see a few practical problems with it. Here are two that spring to mind:

Central Heating: When the clocks go back, I change the clock on my central heating timer and everything works fine. If I simply changed my working patterns without changing the clocks, then I'd have to reprogram my central heating for each day in the week to make sure it came on early enough. That's much more of a hassle than just changing the clock. I guess you could design central heating timers to do all that for you at the push of a button, but good luck trying to convince everyone to spend money on a new central heating timer.

TV scheduling: When I get home from work, I like nothing better than making some dinner and relaxing in front of The One Show. If I start finishing work an hour earlier, my schedule is thrown out and I have to eat my tea whilst watching the news, which is much less entertaining. Or are the TV schedules going to change? In which case, that's going to piss off my neighbour who always goes out during the week and records The One Show. He's now going to have to reprogram his video recorder twice a year.

Now, you could argue that these are pretty minor problems in the grand scheme of things, but they would affect an enormous amount of people. That's the price we'd have to pay in order to relieve a much worse problem that affects a very small number of people. In effect you're just spreading the hassle around and diluting it. That's great for someone like you, who currently bears the full brunt of the hassle, but I think you'll have a job convincing other people that their levels of hassle should increase just to make your life easier :)

 
aTao
758975.  Tue Nov 09, 2010 7:38 am Reply with quote

Quote:
One customer had a company policy, though, that all servers had to run in the Central timezone.

Quote:
What should the software have done.


Unusual that ANY computer ANYWHERE does not use UTC as its main clock with local offset adjusted for DST, but lets say they do... The software should have got its own UTC using network connection to just about any time source.

 
Jenny
759133.  Tue Nov 09, 2010 9:49 pm Reply with quote

The day the clocks went back I just left my computer on all night, and when I came down in the morning the magic computer pixies had re-set the clock on it for me.

 
nitwit02
759135.  Tue Nov 09, 2010 9:59 pm Reply with quote

Same here, Jenny. Harry Potter arranged it ...

 

Page 2 of 4
Goto page Previous  1, 2, 3, 4  Next

All times are GMT - 5 Hours


Display posts from previous:   

Search Search Forums

Powered by phpBB © 2001, 2002 phpBB Group