View previous topic | View next topic

Hours in a day

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

pedxing
756987.  Mon Nov 01, 2010 7:24 pm Reply with quote

I don't believe this has been asked on the show, but my memory may be faulty. Or it may be in one of the books (which I haven't read). I haven't found any mention of it searching the forums, either, but apologies if this has come up before.

How many hours are there in a day?

Klaxon for saying 24, and I'm not talking about leap-seconds. As the iPhone Daylight Savings Time (DST) bug should have reminded everyone, many countries have one day a year with 23 hours, and another with 25 hours. DST shifts cause havoc in computer programs as it can be almost impossible to figure out the "correct" time to do something.

For example, suppose something is programmed to happen every day at 2:15AM. On the "Spring Forward" day (which is different in every country but will happen next year on March 27th in the UK and March 13th in most of North America) there is no 2:15AM. The clock skips directly from 2:00:00 to 3:00:01. Oops.

The other end of the DST shift is just as bad. Suppose something is programmed to happen at 1:15AM. On the fall back day (October 30 in the UK next year) the question needs to be asked "which 1:15AM?", since the clock counts through from 1:00:00 to 1:59:59 and then returns back to 1:00:00 and repeats the hour.

Then there is Date Arithmetic. Often you have a time today and have to get the same time tomorrow. How do you do it? Sounds easy, right, just add 24 hours. But if the day isn't 24 hours long that can add or lose an hour. This is probably the problem on the iPhone.

It is easy to see why programmers consider the idea of tampering with something as basic as time a grotesque notion. What do these time shifts actually get you? As one comedian described daylight savings (I'm afraid I've forgotten who it was), "You want to be taller? Chop off your head and stand on it." The logic is about the same.

The claim is made that DST saves money. Fine. Don't eliminate DST. Eliminate standard time. Just stop with the shifts, already.

My thoughts and prayers are with the iPhone developers right now. I've been there, man, I feel your pain.

 
Zebra57
756988.  Mon Nov 01, 2010 7:25 pm Reply with quote

Welcome to QI forum pedxing

 
dr.bob
757047.  Tue Nov 02, 2010 4:54 am Reply with quote

pedxing wrote:
How many hours are there in a day?

Klaxon for saying 24, and I'm not talking about leap-seconds. As the iPhone Daylight Savings Time (DST) bug should have reminded everyone, many countries have one day a year with 23 hours, and another with 25 hours.


So we have 363 days of 24 hours, one of 23 hours, and one of 25 hours.

Or, in other words, on average a day is 24 hours.

pedxing wrote:
DST shifts cause havoc in computer programs as it can be almost impossible to figure out the "correct" time to do something.


It's clearly not "almost impossible" for computer programs to cope with DST. Daylight Savings Time has been around a lot longer than computers. Computer programmes have always had to cope with DST. It's not a new thing.

Just about every computer system and OS on the planet has been developed to cope with DST. There are a gazillion pre-written date arithmetic routines for just about every programming language on the planet. The fact that the iPhone seems incapable of dealing with DST shows a fantastically poor level of quality control on the part of Apple's developers.

pedxing wrote:
What do these time shifts actually get you?


More light in the evening during summer, when people can get out and about after work, and more light in the morning during winter, when there's precious little light to go around and kids walking to school will be less likely to be killed in a road accident if it's light.

pedxing wrote:
My thoughts and prayers are with the iPhone developers right now. I've been there, man, I feel your pain.


The only thing I feel for iPhone developers right now is contempt.

 
pedxing
757162.  Tue Nov 02, 2010 12:34 pm Reply with quote

Quote:
Or, in other words, on average a day is 24 hours.


Yep. On average. Not on each day specifically. Which is the point of the post.

Quote:
Just about every computer system and OS on the planet has been developed to cope with DST.


To figure out the date and time, that is true. To figure out a span of time, that is false. The reason is there is no one right answer. This is more technical than I had intended to get, but since you made the claim...

You can base a time span on duration, eg. 4 hours, or you can base it on a start and end time, often called a period, such as 11PM to 3AM. Although these things seem to be the same, because of DST they have differences that can often play out subtly.

For example, I designed scheduling software so that work shifts for people could be defined. We specified that any server running our software had to be running UTC so as to avoid DST issues.

One customer had a company policy, though, that all servers had to run in the Central timezone. The software scheduled shifts for their teams around the world. A shift that was supposed to start at 8:30AM local time was actually 2:30AM in the Central timezone. And guess what. On Spring forward day, there is no 2:30AM. That is an imaginary time.

What should the software have done. What do we think is the right answer? 1:30AM? 3:30AM? 2:00/3:00? Whatever it was the customer expected from an imaginary time, it wasn't what our software did. So I spent the next 36 hours generating a patch that would correct the behaviour, which was fine until the next DST shift when my fix turned out to have an effect on another customer with an equally bizarre setup and I had to be called in again. I hate DST shift days.

When you are working across different timezones with different DST shift dates, you can get truly bizarre behaviours because one place has a 23 or 25 hour day whereas the other place does not. You may prefer not to believe that this is a nightmare that causes a huge amount of manpower to squish bugs, but I assure you it is.

Quote:
The fact that the iPhone seems incapable of dealing with DST shows a fantastically poor level of quality control on the part of Apple's developers.


Something went wrong with their process, I'll grant you that. Whether it was with their Quality Assurance department or management deciding to release with this known bug, I don't know. But given what I've said, it should be easy to see how the bug happened.

The iPhone can't just be in a loop saying "Is it time for the alarm to go off yet?" If it did that, the OS could deal with DST and all would be well, but you would also drain the battery in a hurry. So what I imagine happens is the software looks at the current time, calculates how long it will be before the next event, and then it goes to sleep for that long. If it is 11PM and the alarm is for 7AM, then go to sleep for 8 hours. Maybe. Or maybe 9. Or 7. Or, if you are in a timezone with a 2 hour DST offset, for 10 hours. Or 6.

Of course this is all solvable, but the notion that a day has 24 hours is so ingrained that this variation is often overlooked even by experienced programmers. I often find that regular people are surprised to find out there are 23 or 25 hours in a some days, even though they know it on a superficial level when they set their clocks forward and back. Ditto with the lack of 2:30AM or the duplication of 1:30AM. They know it, but they don't think it through.

I asked what these time shifts get you:

Quote:
More light in the evening during summer, when people can get out and about after work, and more light in the morning during winter, when there's precious little light to go around and kids walking to school will be less likely to be killed in a road accident if it's light.


No. That's what DST gets you. The shifts get you nothing. Eliminate standard time and you get all those benefits and DST year round.

Another way of saying this is, what does standard time get you that you don't get from DST?

 
Posital
757203.  Tue Nov 02, 2010 3:49 pm Reply with quote

Did someone mention 1 sidereal day = 23 hours, 56 minutes, 4.091 seconds?

 
dr.bob
757363.  Wed Nov 03, 2010 6:34 am Reply with quote

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


Surely it's irrelevant which timezone the customer insists on running their server. All you have to do is convert the local time to seconds since the epoch, do your various date arithmetic, then convert back to localtime, with a quick check to see whether you've crossed a DST boundary.

Granted, that involves constructing a database of when the various timezones implement DST (for some value of "constructing" that includes "downloading it from here), but that just needs to be done once at the beginning of the project. Then for each timezone you only need to compare with two dates in the year. Not exactly an onerous comparison.

pedxing wrote:
The software scheduled shifts for their teams around the world. A shift that was supposed to start at 8:30AM local time was actually 2:30AM in the Central timezone. And guess what. On Spring forward day, there is no 2:30AM. That is an imaginary time.

What should the software have done. What do we think is the right answer? 1:30AM? 3:30AM? 2:00/3:00?


We're talking about a central server scheduling a shift for an employee in a different time zone 6 hours ahead, right? So, for a real world example, a central server in Denver scheduling a shift for an employee in London.

Well, when it's 8:30am local time in London, the time in Denver on spring forward day is 3:30am. Normally the time in Denver would be 2:30am but the time jumps forward from 1:59am to 3:00am, so the time would now be 3:30am. What's so hard about that?

pedxing wrote:
When you are working across different timezones with different DST shift dates, you can get truly bizarre behaviours because one place has a 23 or 25 hour day whereas the other place does not. You may prefer not to believe that this is a nightmare that causes a huge amount of manpower to squish bugs, but I assure you it is.


It shouldn't require a huge effort of manpower simply because so many people have already tackled this problem, so there are many open source solutions to it. Admittedly, if you wanted to write your own code from scratch to deal with it, it would be a pretty complex and tricky problem, but there's really no need to reinvent the wheel.

pedxing wrote:
But given what I've said, it should be easy to see how the bug happened.
[...]
Of course this is all solvable


That's rather my point. The fact that Apple didn't solve it shows that something went seriously wrong when it never should have.

pedxing wrote:
but the notion that a day has 24 hours is so ingrained that this variation is often overlooked even by experienced programmers.


It's a good point, and certainly something that most people don't think about.

However, people involved with creating applications that use date arithmetic should think about this in order to do their jobs properly. For instance, I would point out that just about every sysadmin I know has learnt that you never schedule an ongoing cron job between 1am and 3am.

It's understandable that even experienced programmers make mistakes, but surely that's what QC is for. Nobody said "oh it's understandable that Apple's new iPhone doesn't work if you hold it in your left hand. I feel really sorry for those designers." No, they quite rightly said "what a fuck up! How did that get past QC?"

pedxing wrote:
I asked what these time shifts get you:

Quote:
More light in the evening during summer, when people can get out and about after work, and more light in the morning during winter, when there's precious little light to go around and kids walking to school will be less likely to be killed in a road accident if it's light.


No. That's what DST gets you. The shifts get you nothing. Eliminate standard time and you get all those benefits and DST year round.


You can't get more light in the evening during summer and more light in the morning during winter without shifting the time.

If we stay on GMT all year, then on the longest day we end up with the sun rising in London at 0340 when everyone's asleep, and setting at 2023, when people are likely to still be out and about. By switching to BST, we lose an hour's sunlight at 4am, but nobody cares 'cos they're mostly asleep. In return we get an extra hour's sunshine at 9pm when most people are still awake.

If we stay on BST all year, then on the shortest day the sun rises in London at 0901, when most people are already at work or school, and sets at 1655, when most people are still at work. So, by switching to GMT, we get an extra hour's sunlight around 8:30am when people are going to work/school (helping to reduce accidents). In return, we lose an hour's sunlight around 4:30pm, when most schools have already emptied, and most office workers are still at work, so no loss there.

Bear in mind, those sunrise/sunset times are for London. The further north you go, the more acute the problem becomes.

 
suze
757456.  Wed Nov 03, 2010 12:48 pm Reply with quote

Does the current proposal envisage using UTC+1 all year round, thus no longer having clock changes twice a year? Or does it envisage using UTC+1 in winter and going forward to UTC+2 in summer - thus placing the UK in the same time zone as most of western Europe?

I think there'd be resistance to the latter. It would mean that in high summer it wouldn't be dark until 11pm - even later in Scotland - which might impact on getting schoolkids to go to bed.

If the former, well there are perhaps some minor advantages for England, but some somewhat larger disadvantages for Scotland.

In which case, is there actually any reason why the whole of the UK has to use the same time zone? Countries like the USA and Canada seem to manage perfectly well with not doing.

Scotland could continue with the present arrangements, so the only difference would be that in winter it would be an hour later in England than in Scotland. And since most of Scotland is west of most of England (Edinburgh lies west of Cardiff, which is perhaps not as well known as it should be), that would be no great surprise.

 
samivel
757469.  Wed Nov 03, 2010 2:39 pm Reply with quote

suze wrote:
Edinburgh lies west of Cardiff, which is perhaps not as well known as it should be


Indeed not. Here's just one example of it not being known.

 
Moosh
757474.  Wed Nov 03, 2010 3:32 pm Reply with quote

suze wrote:
Edinburgh lies west of Cardiff, which is perhaps not as well known as it should be

No it doesn't. Cardiff is at 5129′N 311′W, which is further west than Edinburgh's 5557′N 309′W.

 
pedxing
757480.  Wed Nov 03, 2010 4:13 pm Reply with quote

Quote:
All you have to do is convert the local time to seconds since the epoch, do your various date arithmetic, then convert back to localtime, with a quick check to see whether you've crossed a DST boundary.


Sounds so reasonable. Unfortunately, it is wrong. This is what I am talking about when I say the effects can be subtle. It can be very difficult to understand all the ramifications.

Most of the time, there is a 1 to 1 mapping between seconds since the epoch and the way we count time. For 1 hour a year in many places, though, there are 0 mappings, and for 1 hour a year there are 2 mappings. These aren't in the actual time that passes, you understand, but in the way we count it.

It is as if, under some circumstances, 5 did not represent a collection of 5 physical objects, but instead represented no actual number. And 7 sometimes represented collections of either 7 or 8 objects.

When 5 comes up as a result of calculations, sometimes you want to treat it as 4, and sometimes you want to treat it as 6. And sometimes you want to continue treating it as 5 because this is an intermediate result and later on another calculation will move it away from the nebulous 5.

That is how we are treating time. Our counting system is seriously screwed up.

Quote:
Well, when it's 8:30am local time in London, the time in Denver on spring forward day is 3:30am. Normally the time in Denver would be 2:30am but the time jumps forward from 1:59am to 3:00am, so the time would now be 3:30am. What's so hard about that?


You are making some assumptions here. First, the shift in London will not be static. It is expected to shift with the DST shift in Denver. People in London will suddenly find themselves working a 7 or 9 hour shift for no apparent reason, and the time of their shift will change. Then when London DST changes, the shift time does not change to match the DST time change, so again they are coming in an hour earlier or later. So relying on the London local time buys you nothing in terms of trying to come up with an answer because it is not static.

But the real question is what happens on the server in Denver. It knows nothing about London local time. It only knows that it is supposed to program a shift that starts at 2:30AM Denver time, which is not a real time. There is no mapping to seconds since the epoch.

Quote:
It shouldn't require a huge effort of manpower simply because so many people have already tackled this problem, so there are many open source solutions to it.


As someone who has contributed substantial amounts of code to an open source project to try to deal with this issue, I can tell you that it is not a solved problem. The trouble is that there is no one solution for it. Sometimes you want a day to be 24 hours no matter what. Sometimes you want to take the hour before. Sometimes you want to take the hour after. Sometimes you want to split the difference.

As an example, my software displayed shifts as a bar graph. I had to calculate how many pixels long a bar should be when displayed on the graph. Imagine a timeline with three marks, one for 1:00AM, one for 2:00/3:00AM, and one for 4:00AM. The legend is smart enough to combine 2 and 3 together into the single mark.

Now, in your minds eye draw a shift that starts at 2:30AM. Figure out how to calculate how many pixels over to start drawing. If you know of an open source library that has solved this problem, I'd sure love to hear about it.

Here is another way to think about it. Should an open source library represent a span of time as a start time and a duration or as a start time and end time? These give different results, so any application that uses your library will be stuck with your decision. Which one is right? The answer is neither. In my scheduling software I use one or the other depending on circumstances, and sometimes have to use first one and then the other in the same calculation. And whichever I use, there are likely to be unexpected repercussions in other scenarios.

Quote:
...every sysadmin I know has learnt that you never schedule an ongoing cron job between 1am and 3am.


This just proves my point. This is not a solved problem, it is nasty. People go out of their way to avoid it, even giving up utilization of the computer for automated jobs when it is least likely to be busy doing other things. What a loss of computing resources is caused by the DST shift!

And what do you do when, like me, you can't avoid that time between 1:00AM and 3:00AM?

Quote:
You can't get more light in the evening during summer and more light in the morning during winter without shifting the time.


Sorry, I missed your point about more light in the morning in your previous reply, I guess because I so thoroughly disagree with it. The light lost in the evening is light I really enjoy. Having it get dark at 5:15PM instead of 6:15PM as it did the previous day is something I find depressing. And for what? So that it gets light at 6:30AM instead of 7:30AM? And for that we are going to muck up the way we count time?

Let's agree to disagree on that point. Let's try another angle, one suggested by the global scheduling software I've been describing. If people could be just a little bit flexible then we wouldn't need DST shifts either. Suppose you declared office hours (or store hours) are 9AM-5PM except November to February when they are 8AM-4PM. Bingo, we have solved the problem without a DST shift.

 
suze
757508.  Wed Nov 03, 2010 5:51 pm Reply with quote

Moosh wrote:
No it doesn't. Cardiff is at 5129′N 311′W, which is further west than Edinburgh's 5557′N 309′W.


Hmmm. I'm using the Location Sensor on Microsoft Autoroute for this, and it's telling me that the Scott Monument in Edinburgh - seems a reasonable point to choose, on Princes Street 100 yards from Waverley station - is at 3.194 W.

I've never been to Cardiff so I don't really know where the "centre" ought to be. Since they are only 200 yards apart, I've chosen a point half way between Cardiff Central station and the Millennium Stadium. And that point is at 3.180 W.

Ergo, Edinburgh continues to be west of Cardiff - albeit by less than one mile.

 
mckeonj
757512.  Wed Nov 03, 2010 6:14 pm Reply with quote

Actually, in the UK, Edinburgh is North of Cardiff.

 
pedxing
757542.  Wed Nov 03, 2010 9:01 pm Reply with quote

Quote:
Does the current proposal envisage using UTC+1 all year round, thus no longer having clock changes twice a year?


That is what I was proposing for the UK, yes. But it only matters if the whole world gives up the insanity of daylight savings time shifts. If Scotland keeps both DST and standard time then everyone still has to deal with places where there are 23 and 25 hour days, and the mayhem continues.

An alternate proposal is that each location choose standard office hours that are most beneficial for sunlight at that location for the time of year. Then the UTC offset almost doesn't matter except to make the day ends while most people are asleep.

[Not that I expect _any_ proposal to do any good. People are too resistant to change.]

 
themoog
757698.  Thu Nov 04, 2010 9:02 am Reply with quote

Something I've never been able to find a satisfactory answer to is why the timeshift occurs at such different sunrise/set times in Spring and Autumn.

Taking Carlisle as an example (rise/set/length all UTC)
March 27th: 05:57 / 18:39 / 12 h, 42 min
October 30th: 07:11 / 16:40 / 9 h, 29 min

If GMT is good until 27th Mar why wait until the end of Oct and not change in the middle of September when the conditions are about the same? Or if we need BST throughout October why do we not need it in March?

 
dr.bob
757724.  Thu Nov 04, 2010 11:03 am Reply with quote

pedxing wrote:
You are making some assumptions here. First, the shift in London will not be static. It is expected to shift with the DST shift in Denver.


I have literally no idea what this means.

pedxing wrote:
But the real question is what happens on the server in Denver. It knows nothing about London local time.


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.

If it doesn't, it can't function properly.

pedxing wrote:
Should an open source library represent a span of time as a start time and a duration or as a start time and end time?


That depends entirely on the application, and is something that needs to be established at the planning stage. A program that adds up how many hours people have worked over the year will represent time as a start time and a duration, while something like a video recorder will represent time as a start time and end time.

There are certainly different approaches based on the application, but always remember the six P's: Proper Preparation Prevents Piss-Poor Performance.

pedxing wrote:
This just proves my point. This is not a solved problem, it is nasty.


It's nasty, I grant you, but it's solved by simply not running anything at that time of day.

pedxing wrote:
And what do you do when, like me, you can't avoid that time between 1:00AM and 3:00AM?


OK, imagine I had a client that insisted on a cron job running at 1:30, and another running at 2:30. 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. Then ask them how they want to deal with that situation.

The March one is easy. Write a piece of code to say "check the date: is it spring forward day? If so, check to see if the 'we've been here before' file has been created on the filesystem. If it has, this is the second 1:30, so delete the file. If it hasn't, this is the first 1:30, so create the file." Hey presto, your code now knows whether it's the first or second 1:30. It can then run the cron job on one or 'tother, depending on what the client desires.

October one is even easier. Just ask the client if they want it running at 1:30 or 3:30 on that day, then set up a piece of code that runs from cron on 1:30 or 3:30 (depending on what the client requests) and simply does "is this the fourth sunday on October? If yes, run the code, if no, do nothing".

pedxing wrote:
The light lost in the evening is light I really enjoy. Having it get dark at 5:15PM instead of 6:15PM as it did the previous day is something I find depressing.


Not sure where you live that the sun sets at 6:15PM on October 30th. Even in Plymouth it set at 5:57PM, while up here in Edinburgh it set at 1737 on October 30th, and 1635 on October 31st. So it went from setting a little after work to setting a little before the end of work. Not such a big deal for a lot of people, I'd warrant.

pedxing wrote:
And for what? So that it gets light at 6:30AM instead of 7:30AM?


Again, I'm not sure of where you're living. In Plymouth, DST meant that the sun rose at 0706 instead of 0806. That maybe not such a big deal, but remember that's at the very start of DST. By midwinter, the sun is rising at 0804. If we didn't put the clocks back, the sun wouldn't come up until 0904, when everyone's already at work/school.

Here in Edinburgh the sun wouldn't come up until 0942. Frankly, I'm not too keen on the sun rising three quarters of an hour after I get in to work.

pedxing wrote:
Let's try another angle, one suggested by the global scheduling software I've been describing. If people could be just a little bit flexible then we wouldn't need DST shifts either. Suppose you declared office hours (or store hours) are 9AM-5PM except November to February when they are 8AM-4PM. Bingo, we have solved the problem without a DST shift.


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

And think of all those poor computer programmers. If you give someone a programme to calculate working shifts, the client will say "OK, I want to enter a shift that starts at 9AM March - October and 8AM November - February." The client isn't going to want to change the start time manually, so the scheduling software will have to figure out something about the local working times of wherever the employee is based so that it knows when to change the start time of the working shift.

I fail to see how that will make things so much better.

 

Page 1 of 4
Goto page 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