View previous topic | View next topic

Hours in a day

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

tchrist
759383.  Thu Nov 11, 2010 7:57 am Reply with quote

Jenny wrote:
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.

Don't forget to adjust your digital cameras. They don't have zoneinfo files built into them. You have to tick or untick the DST flag manually.

 
Jenny
759494.  Thu Nov 11, 2010 3:27 pm Reply with quote

Fortunately I don't have a digital camera quite that complicated!

 
Moosh
759531.  Thu Nov 11, 2010 6:29 pm Reply with quote

tchrist wrote:
Jenny wrote:
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.

Don't forget to adjust your digital cameras. They don't have zoneinfo files built into them. You have to tick or untick the DST flag manually.


As someone said on twitter,

*looks at watch*
*looks at phone*
*looks at watch*
"why can't you be more like phone?"

 
tchrist
759540.  Thu Nov 11, 2010 7:21 pm Reply with quote

Jenny wrote:
Fortunately I don't have a digital camera quite that complicated!

Wanna bet? All digital cameras I’ve heard of carry EXIT data. That includes the current time and date.

--tom

 
tchrist
759541.  Thu Nov 11, 2010 7:24 pm Reply with quote

Moosh wrote:
As someone said on twitter,

*looks at watch*
*looks at phone*
*looks at watch*
"why can't you be more like phone?"

I know somewhere that the phone won’t be right for, but the watch will. Go down the Four Corners area, where CO+NM+AZ+UT converge. All of the Navajo Nation follows DST, even the part in AZ, which doesn’t, except for the Hopi enclave within the Navajo Nation, which again does not.

You have nested donut-hole timezones. Your phone will never get it right. Your watch, might.

--tom

 
Neotenic
759555.  Thu Nov 11, 2010 7:46 pm Reply with quote

mmm.... donut time.

 
Alfred E Neuman
759745.  Fri Nov 12, 2010 4:10 pm Reply with quote

dr.bob wrote:
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.


In a previous life, I worked for the largest bank in the country, and our section was responsible for the systems software running on all the computers used in the branches across the country. We had a scheduled job that ran on the servers every evening before midnight, which consisted of downloading any updates (often none) to all the branch servers, triggering a download from each branch server to all the workstations in the branch, and when that was done, forcing each and every server and workstation to reboot. The reboot happened whether there was a download or not, as everyone knows that it can't hurt :-)

We were running short of time for our job to run, as there were increasing demands from other departments for time to run their jobs, and we were anticipating having to roll out the first copies of anti virus software, so the decision was made to run our job at 1am, and I was tasked with changing the schedules. It was a friday afternoon, the last in the month, which is about the busiest time that bank branches have during a month, usually with queues snaking across the banking halls. I logged on, and made the changes to the schedules, saved the file and exited. And watched in horror as the system checked the job, and decided that it was meant to have been run around 13 hours ago, and dilligently ran the job right then. Luckily network monitoring was not that sophisticated in those days, and each branch only knew that they had gone down, but luckily came right back up, and never realised that each and every other branch had the same experience.

I wandered over to the boss's desk and mentioned that the server had decided to run the job immediately, and his face was a picture. I then suggested that if no-one asked us what had happened, we should not bother upsetting them by mentioning it. And no-one ever did ask.

 
Alfred E Neuman
759748.  Fri Nov 12, 2010 4:13 pm Reply with quote

Oh, and to get back on topic, we don't do daylight saving here, but at least when it's daytime, the sun shines. Brightly.

 
pedxing
760388.  Mon Nov 15, 2010 2:50 pm Reply with quote

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

Quite right. When I was applying Natural Language Processing to legal cases, I had to deal with cases that were cited, including their dates. That meant dealing with cases going back to the Magna Carta. 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.

It became on odd thing, because Australia, like Canada, used the British common law as a basis for its law. This meant that Australian legal cases could reference cases before 1752, but one could not claim that dates in Australia changed in 1752 because Captain Cook did not land there until 1772. So it is hard to know how to convert dates before 1752 in Australia. Should it have used Portuguese dates? Dutch? An Aboriginal calendar? Who knows?

Fortunately, in my case I could ignore the problem. There was no need to convert the dates to the local country.

Quote:
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.


As I've said before, I agree that there is something seriously wrong with its processes. But as far as the developer is concerned, I know that the problem was more subtle than most people are realizing.

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).

Now build a framework on this buggy (but seemingly correct) function and you have unexpected results later on for certain edge conditions. Yes, yes. I know that the issue can be dealt with at another level. But the abstraction we have with this function hides whether the issue has been dealt with already or not.

The difference between this example and the equivalent for leap years is an interesting one to me. People are far more aware that the number of days in a year is not necessarily 365 than they are concerning the number of hours in a day not necessarily being 24. Anyone writing a function for days in the year is going to ask, "What if the year is divisible by 4?" If they know their stuff, they may also ask "What if it is divisible by 100? or 400?" But for hours in the day, you won't find many who ask, "What about DST shift days?" I guess it is because leap days are almost 1 in every 4 years, and DST shift days are just over 1 in 180 days.


Last edited by pedxing on Mon Nov 15, 2010 4:52 pm; edited 3 times in total

 
pedxing
760392.  Mon Nov 15, 2010 3:21 pm Reply with quote

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 have to admit that I am running out of ways to explain the situation.

Quote:
Therefore it is necessary to ask the client how they want to tackle this problem.


I'm not there. The shift is scheduled months after the system has been sold to them, and they encounter the issue almost a year after that.

I've already given clear instructions on how to handle the problem: run the server in UTC. Then there are no imaginary times or duplicated times. 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.

Fortunately, it is very rare to find a company that does not allow the servers to run UTC. But when it happens, boy does it cause problems.

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 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.

The application is actually about communications. When something goes wrong, it makes sure the right people are told about it. This means knowing their schedules, which is why I need to worry about all this time stuff.

The software is used for all kinds of things, including:

- stopping a bank lending a currency if an exchange rate dips too low
- gathering a surgical team to deal with an emergency situation at a hospital
- contacting members of a team to deal with a terrorist alert at an airport
- contacting people in the event of an emergency (like a fire or a tsunami)

So there is a lot at stake if I get it wrong. Not just millions of dollars, but lives could be lost if I don't contact the right people every time.

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


Last edited by pedxing on Mon Nov 15, 2010 3:46 pm; edited 1 time in total

 
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.

 

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