View previous topic | View next topic

Hours in a day

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

pedxing
760396.  Mon Nov 15, 2010 3:40 pm Reply with quote

Quote:
The software should have got its own UTC using network connection to just about any time source.

That certainly would have been a bugfix that would have worked. It wasn't the one I chose, and it would have had unintended consequences to some of the shifts that were previously scheduled (the shifts in London would have become much simpler, for example), but it would have worked.

But hindsight is 20/20. Should I have foreseen the issue altogether and implemented NTP in my application from the start? I already recommended all the servers in the cluster of nodes for my application synchronize with a time server. I already recommended servers run in UTC. To me, before I ran into this situation, implementing NTP would have seemed like wasted effort that could better be spent on other features.

 
pedxing
760418.  Mon Nov 15, 2010 4:30 pm Reply with quote

At the risk of spamming this thread, I'll add one more message today. Here in Canada there were a couple of interesting stories and links that came up due to our DST shift:

1) http://www.cbc.ca/news/pointofview/2010/11/time-change-should-it-be-scrapped.html

In this informal web poll, 82% of British Columbians would prefer to see the DST shift scrapped.

2) http://www.discovermoosejaw.com/index.php?option=com_content&task=view&id=14686&Itemid=399

In contrast, Saskatchewan (which has no DST) is feeling left out and so is going to run a referendum to decide whether to adopt it.

3) http://www.thebarrieexaminer.com/ArticleDisplay.aspx?e=2843540

Two boys get confused about when darkness falls due to the DST shift and spend a night huddled together in a ditch, trying to keep warm.

4) http://www.icbc.com/news/mar11-03

In British Columbia on the Monday following Spring Forward day, there is a 23% increase in car accidents compared to the Monday previous.

5) http://www.youtube.com/watch?v=-J1NHzQ1sgc&feature=player_embedded

This one is just for fun, a scene from the West Wing.

 
suze
760447.  Mon Nov 15, 2010 6:03 pm Reply with quote

Did any of these polls ask about Canada's slavish adherence to starting and ending DST at the same time as the USA, and thus changing the rules every time the USA does?

Newfoundland came quite close to saying "no" last time that Ottawa asked/told the provinces to follow US practice; there are those who think it should have stuck to its guns.

 
dr.bob
760544.  Tue Nov 16, 2010 10:02 am Reply with quote

pedxing wrote:
Quote:
Why would you need them to run their server in UTC?


Because there is a 1 to 1 mapping between UTC and milliseconds since the epoch that does not exist in other timezones.


I understand that, though your answer doesn't tackle my very next sentence when I suggested:
Quote:
You know what timezone the server is running, so just convert to UTC before you start.


pedxing wrote:
The trouble is that many of my customers are Fortune 500 companies and I am a tiny software vendor. In the battle between my instructions and their company policy, guess which one wins.


Oh yeah, I feel your pain. I once worked for a company that produced a website for the Bank of Scotland. As you might imagine from a major financial institution, the BoS had pretty stringent rules about only allowing software that had been officially approved by their IT team to be run on their computer systems. Unfortunately, their IT team were pretty slow on the uptake, so the only web browser that had been officially approved was a five-year-old version of IE. The first time we showed them the website we'd created on that browser, everything broke, so we had to go back and completely rewrite the entire site.

pedxing wrote:
Quote:
If the client wants to perform something at a time of day that doesn't exist, then it's not possible.


I can't have that failure mode, ever.


I wouldn't describe "not being able to do something that's physically impossible" as a "failure" :)

If the client asked to schedule a shift that began on November 31st, that would be similarly impossible.

pedxing wrote:
I haven't actually described what my product does, but perhaps explaining it will give a better idea of why I have to cope with things like imaginary times and duplicate times.


Thanks for the explanation. That was really interesting. It does sound as though your software does some pretty complex things that I can't even begin to get my head around. I must admit that, on reading the description, I just felt very glad that I wasn't responsible for that kind of thing.

I take my hat off to you, sir.

pedxing wrote:
Again, I think I've said all I can about this. If you are still not convinced then you clearly never will be.


I think there are two different points here.

The first point is that DST shifts cause problems. I certainly agree with that, though I'm not sure I share your conviction that this is an adequate reason for doing away with DST altogether.

The second point is that clients are quite often brainless fuckwits who are incapable of following simple instructions. The fact that your software is incapable of dealing with the stupidity of clients is not something I see as a failure because, frankly, given the depth of stupidity of some clients, we'd need several orders of magnitude increases in computing power to deal with that shit. However, I'm even less convinced that we should do away with DST simply to cater to the brainless fuckwittedness of clients :)

pedxing wrote:
3) http://www.thebarrieexaminer.com/ArticleDisplay.aspx?e=2843540

Two boys get confused about when darkness falls due to the DST shift and spend a night huddled together in a ditch, trying to keep warm.


It's not clear that it was caused by a DST shift. The article states:
Quote:
Const. Peter Leon said police don't believe Tyson Fildey, 10, and his brother five-year-old Mason Fildey-Holyj, were taken from their Rainbow Valley Road West home.

"We don't think that was the case," said Const. Leon. "It's more than likely the boys wandered away from home, got disoriented with the change of time (from daylight saving) and darkness falling quickly."


Sounds like they don't really know what happened.

pedxing wrote:
4) http://www.icbc.com/news/mar11-03

In British Columbia on the Monday following Spring Forward day, there is a 23% increase in car accidents compared to the Monday previous.


I'm always very dubious about car accident figures since they tend to be classic examples of small number statistics, not to mention other factors at work.

I took a look at some of the car accident figures on the Insurance Corporation of British Columbia website. They didn't have figures up to 2009 (as quoted in that article) so I looked at the five years from 2003-2007.

The first thing I noticed was there's a general increase in accidents as the year goes on. So March sees more accidents than February, and April has more than March and so on. So the fact that there are more accidents after DST than before it may be influenced by this.

The other thing I noticed were the pretty large standard deviations in five year average figures. If you compare the figures for accidents for any particular year against the five year average, you'll notice the standard deviation is 15% for February, 13% for March, 25% for April, and 23% for May. This is comparing the average for the month against the five-year average. Figures for individual days would, I imagine, vary even more. In the context of this, a difference of 23% mentioned in the article doesn't seem so extraordinary and could just be caused by statistical variation though, without seeing the figures the article was based on, it's impossible to be sure.

 
pedxing
760573.  Tue Nov 16, 2010 2:10 pm Reply with quote

Quote:
In the context of this, a difference of 23% mentioned in the article doesn't seem so extraordinary and could just be caused by statistical variation though, without seeing the figures the article was based on, it's impossible to be sure.


Your analysis would be correct if ICBC were looking at the data for only one year, but it has 35 years worth of data to go on. Even when the Spring Forward day changed in 2007, they still maintained that they are seeing a 23% increase from the previous Monday. Since the figure does not change much year to year, it makes sense to me that they are using a large number of years to generate that figure.

ICBC spends a fair amount on publicity on Spring Forward day to give drivers advice on how to drive more safely on that day. Presumably they do so because they are convinced they will end up spending less on claims as a result.

 
dr.bob
760750.  Wed Nov 17, 2010 7:10 am Reply with quote

pedxing wrote:
Your analysis would be correct if ICBC were looking at the data for only one year, but it has 35 years worth of data to go on. Even when the Spring Forward day changed in 2007, they still maintained that they are seeing a 23% increase from the previous Monday. Since the figure does not change much year to year, it makes sense to me that they are using a large number of years to generate that figure.


This was not clear from the article, which only mentioned comparing against a five year average.

 
Leith
761058.  Thu Nov 18, 2010 6:22 pm Reply with quote

pedxing wrote:
5) http://www.youtube.com/watch?v=-J1NHzQ1sgc&feature=player_embedded

This one is just for fun, a scene from the West Wing.

Ah, a classic episode. "I'm Toby Ziegler. I work at the White House" :)
I recall that being my first encounter with question "what time is it in Indiana?".

pedxing wrote:
The Calendar Act of 1750/1751/1752 caused a bit of headscratching for me.

I don't know how well known it is in England, where it is reputed to have caused riots as people asked how they were supposed to pay rent in a September with only 19 days, or how well known it is on these forums (I suspect well known but I haven't searched), but outside of England almost no one has heard of it. I remember my delight when I ran the Unix "cal" program for September 1752 and got back the weird calendar for that month.

Indeed. I think Suze first regaled us with that one (post 119933). I'm not sure how widely known it is in the UK generally. I only stumbled across it myself a few years back, whilst trying to make sense of the dates in my family tree.

pedxing wrote:
Let me give you a concrete example. Suppose that deep down is a routine that returns the number of seconds in an hour. Seems easy to write. Return 60 seconds/minute * 60 minutes/hour = 3600 seconds per hour.

Would it honestly occur to you when writing this function that under some circumstances the answer is 7200 seconds per hour? Or 0 seconds per hour? Or even other answers for previous years (there have been DST offsets that are different from 1 hour).

Well if it's a function rather than a constant then that should start the alarm bells ringing straight away. If the task is to return the number of seconds in a specific hour (the only scenario I can immediately think of in which a value other than 3600 makes sense) then I'd need to be very clear about what sort of times the function is required to deal with. If it is UTC time then I may need to account for leap seconds and warn against using it for future dates.

If I'm doing arithmetic with local times, then the obvious consequence should be that I'll need to think about how (or if) the function needs to deal with time zones and DST and clearly document its behaviour and intended usage.

Taking a step further back, I might question the purpose of such a function in the first place. Trying to convert between units of elapsed time to relate seconds to hours or hours to days is inevitably going to be error prone, especially working in local time. Using a calender representation for working in hours or days is usually a safer approach.

Here's an example of an inexperienced iPhone developer making a DST error of the sort you describe in your first post (aided, I note, by the Apple Date and Time Programming overview docs, which don't seem to even mention DST):
Working with Dates and Date offsets in iPhone Development
Sure, many programmers could make that mistake on a bad day, but in this case the problem was discovered with some cursory testing, as should the iPhone clock bug have been.

I can see your project potentially involves some date/time arithmetic of nightmarish complexity, though. You certainly have my sympathies there, and I'm thankful that the industry I work in these days has sufficiently well established guidelines for time handling that I rarely have to deal with time zones or DST (though they are rather fond of 'day of the year' format which can be a pain to work with as an end user).

Thinking of time adjustment-free worlds, I wonder how the Chinese get on with their one mega-time zone?

 
pedxing
761182.  Fri Nov 19, 2010 1:04 pm Reply with quote

Quote:
Well if it's a function rather than a constant then that should start the alarm bells ringing straight away.

Sorry, I didn't intend a focus on specifics. I was just trying to come up with the simplest example that I could to explain the general concept that:

1) sometimes an apparently simple solution has unexpected consequences in edge cases, and

2) Using that simple solution in other situations can hide the fact that the edge cases have not been accounted for.

The 0/3600/7200 second hour seemed like an example that everyone who has been following this thread could wrap their heads around. I didn't mean to suggest anyone would actually write a function like this.

In fact, judging from the reports Apple has issued about who is affected by this bug, I am almost certain the problem is either buried deep in an iCal library or in code that relies heavily on iCal. I've provided lots of bugfixes to an iCal library myself as well as customizing it for my own use, and I can tell you things can get pretty complicated in there.

I am also fairly certain that fixing the problem in iOS without causing problems elsewhere is extremely difficult. I say that because even with at least a weeks notice, Apple was unable to provide a fix for the North American market. You know that with the blow to their reputation that this has been, if it had been possible they would have done it.

So if you guys want to continue thinking that all the Apple developers are just idiots, go ahead. Myself, I think it is our own ignorance that leads us to think that.

Quote:
Thinking of time adjustment-free worlds, I wonder how the Chinese get on with their one mega-time zone?

Heh. You think I'm a lunatic for wanting to adopt DST year-round? If I were king of the world everyone would keep time in a single timezone, UTC, everywhere and at all times.

 
Leith
761221.  Fri Nov 19, 2010 3:55 pm Reply with quote

pedxing wrote:
Sorry, I didn't intend a focus on specifics. I was just trying to come up with the simplest example that I could

Then my apologies in return. My perception was you were presenting a naively simplistic example to illustrate what you felt we were missing, but I see your intention was to keep the discussion more broadly inclusive.

pedxing wrote:
I am also fairly certain that fixing the problem in iOS without causing problems elsewhere is extremely difficult. I say that because even with at least a weeks notice, Apple was unable to provide a fix for the North American market. You know that with the blow to their reputation that this has been, if it had been possible they would have done it.

That's a good point, and could certainly explain how an issue like that may not have shown up in earlier testing. That scenario would be less indicative of extreme carelessness by the (presumably) few individuals involved specifically in the offending clock application, though perhaps more worrying as regards the general robustness of the iPhone's core libraries.

pedxing wrote:
Heh. You think I'm a lunatic for wanting to adopt DST year-round? If I were king of the world everyone would keep time in a single timezone, UTC, everywhere and at all times.

Well, your revolution would be easy to schedule if nothing else :)

 
bobwilson
761269.  Fri Nov 19, 2010 11:41 pm Reply with quote

It may have been covered before but ......

time is not constant (see Einstein for references). Specifically, (and pedx does seem to be intent on specifics) - time is a function of acceleration - and gravity affects acceleration. More prosaically, if we set all clocks to 12:00:00 simultaneously (whatever that might mean) - within 12 terrestrial months none of them would agree.

If Apple (or developers) can't figure out the rather simplistic approximation of time agreed on by Newtonian physics then they're really fucked when it comes to the more realistic notions of time of Einsteinian physics.

Put another way (as dr.bob points out) any idiot can write a program and a user-guide that can cope with imposed time changes that are well-publicised. If they can't manage that basic level of competence then there really is nothing other to say than don't write computer programs, do something more in line with your level of competence - I suggest picking up litter.

Quote:
Heh. You think I'm a lunatic for wanting to adopt DST year-round?


Yep. If you think that adopting a universal time system because some programmers are incompetent enough to be unable to include well-documented systems to cope with human foibles - in other words, to make humanity the servant of machines - then you truly are a lunatic and I claim my five quid.

 
pedxing
761376.  Sat Nov 20, 2010 1:12 pm Reply with quote

Quote:
If Apple (or developers) can't figure out the rather simplistic approximation of time agreed on by Newtonian physics then they're really fucked when it comes to the more realistic notions of time of Einsteinian physics.


You mean someone on the ISS with an iPhone is going to be woken up a few microseconds before Mission Control does it? I'm guessing that is in the acceptable range of behaviours.

Of course, iPhones have GPS where relativistic issues come into play, not just time dilation but the difference with time passing in a heavier gravitational field. But since that issue is fixed by running the clocks on the GPS satellites a little slower, I don't think Apple has much to do with it.

 
dr.bob
761727.  Mon Nov 22, 2010 5:38 am Reply with quote

pedxing wrote:
So if you guys want to continue thinking that all the Apple developers are just idiots, go ahead. Myself, I think it is our own ignorance that leads us to think that.


I wouldn't say that Apple developers are "just idiots", nor would I say that I would be able to do a better job than them.

However the fact remains that countless other operating systems, including, one must assume, previous versions of iOS, managed to deal with this problem correctly.

The fact that iOS 4.1's recurring alarms don't cope with DST is bad. The fact that this then got past QA and out into the real world shows that something went very, very wrong with Apple's development processes.

 
astrobumpkin
762099.  Tue Nov 23, 2010 12:47 pm Reply with quote

I find it easiest to use Universal Time (UT) which astonomers world wide use and its equal to Greenwich Meantime. It lasts for the entire year...

I dont bother to change my watch to DST/BST.. I just mentally make the adjustment for BST if I need to know. It works fine and I dont miss appointments etc

 
pedxing
762341.  Wed Nov 24, 2010 11:05 am Reply with quote

Quote:
I dont bother to change my watch to DST/BST.. I just mentally make the adjustment for BST if I need to know. It works fine and I dont miss appointments etc

Thanks, astrobumpkin. You've just become my existence proof.

 
dr.bob
762550.  Thu Nov 25, 2010 9:23 am Reply with quote

Since my wife is a statistician, I will trot out my usual warning about extrapolating a line based on a graph with one data point on it :)

 

Page 3 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