View previous topic | View next topic

Hours in a day

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

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 4 of 4
Goto page Previous  1, 2, 3, 4

All times are GMT - 5 Hours


Display posts from previous:   

Search Search Forums

Powered by phpBB © 2001, 2002 phpBB Group