Unit tests fail when run in Australia
github.com
github.com
Then I was coding on the train home one night and in the tube my hotspot lost connection. Then I happened to notice... with wifi off the tests ran 10x quicker. Pull out netstat.... I see http requests to akamai essentially as each test setUp() is run. It's SSL so I only see a hostname, not the full path, and they just look like this, but the hostname is dynamic: a23-34-132-181.deploy.static.akamaitechnologies.com
I spent 30 mins reviewing our code, grepping my code and packages directories, and stepping thru in a debugger. No luck.
The worst was having a Map keyed on URLs in Java -- turns out URL.equals() and URL.hashCode() do DNS lookups... Easiest 50% test speedup ever!
The other suggestions -- using a SSL proxy -- has been my plan of attack.
- start a test from the IDE,
- wait a second or so,
- manually pause all threads,
- look at the stacks of the threads.
strace -e trace=network ./run_my_unit_testsUse java.net.Uri, or e.g. the equivalent from Jersey or whatever your local framework/HTTP client/... brings with it.
Joshua Bloch used this as an example in one of the brilliant Java Puzzler video series with the net advise of don't depend on non-local state for equality.
[0]: https://mitmproxy.org/, https://mitmproxy.org/doc/ssl.html
[0]: http://nedbatchelder.com/blog/201503/finding_temp_file_creat...
https://jimshaver.net/2015/02/11/decrypting-tls-browser-traf...
http://www.haiku-os.org/legacy-docs/benewsletter/Issue4-22.h...
A Testing Fairy Tale
Two test engineers were in a crunch. The floppy drive they were currently testing would work all day while they ran a variety of stress tests, but the exact same tests would run for only eight hours at night. After a few days of double-checking the hardware, the testing procedure, and the recording devices, they decided to stay the night and watch what happened. For eight hours they stared at the floppy drive and drank espresso. The long dark night slowly turned into day and the sun shone in the window. The angled sunlight triggered the write-protection mechanism, which caused a write failure. A new casing was designed and the problem was solved. Who knew?
The cleaner's vacuum cleaner would occasionally pull out the PS2 cord.
The cool bit, at least to me, is that the mnemonic "spring forward" still works. Likely, this is only cool to me because the whole thing is unusual.
The other odd bit is that some TZs sit on the "wrong" side of the international date line, and thus get interesting offsets such as +13 or +14h from UTC. I think there's some that are -13h too, so the total "length" of day (that is, how long you could remain on a calendar date) is >48h. Thus, at any given time, people in their local time are in as many as three different calendar dates.
There's also a few TZs with half-hour offsets. (e.g., they're something like 4.5 hours off UTC.) There's a 3-hour TZ jump at one point on China's border, I think, because all of China is on a single timezone, and the nation is quite wide, east-to-west.
We've not even gotten to leap seconds, or that 2100 won't be a leap year.
And governments regularly muck with this stuff. The set of timezones and their offsets and DST preferences are constantly changing.
To get anything done, I feel like the general programmer[1] is allowed to assume, at a bare minimum, a Proleptic Gregorian calendar. Anything else just makes handling early (pre-Gregorian) dates madness. (Various geographical locations adopted the calendar at different times, so you end up needing to know where you are to compute the "local" date. Even further back in history the rules get even more odd, and unknown. [2], if I read it correctly, includes a table of when scholars _think_ people inserted leap years.)
Once you go with "Proleptic Gregorian calendar", I think points such as
> Months have either 28, 29, 30, or 31 days.
…are actually always true. Of course, two bullets down is,
> There is only one calendar system in use at one time.
Which is essentially what we're using as axiom here. It's true because we've defined it as such. (Cheating, I admit, but if you're building the next great mobile app, do you care?)
I do wish that site included fold-out sections to de-mystify some of the points.
> Non leap years will never contain a leap day.
Your definition of leap year isn't "year with a leap day"?
> Unix time is the number of seconds since Jan 1st 1970.
> Unix time […] is […] defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, not counting leap seconds.[3]
Again I wish for pop-out explanations, because I'm left to wonder whether POSIX's lack of leap seconds is what the author is hinting at.
I'm bored though, so perhaps I should write a gist showing which of these I believe to hold (and why) and which do not (and why).
[1]: I think anyone breaking this rule would know that their area of interest requires them to break it, and thus know that they need attention.
[2]: https://en.wikipedia.org/wiki/Julian_calendar#Leap_year_erro...
Edit: I am confused about the downvotes. I point out that he can't assume there is only one calendar system in use, even for general software.
Thai Railways is using the Buddhist calendar http://www.railway.co.th/home/
Either way, let's still for the sake of the argument say that all of Iran only uses the Islamic calendar. That still reduces the GP's point from 'to sell software in countries that are mostly Islamic, you must support multiple calendars' to 'to sell software to Iranian customers you must support multiple calendars'. Iran, just to state the obvious, is widely embargoed across the world, and it's quite challenging to sell anything there, legally (I have first hand experience to the extent that it wasn't worth the time for 5 figure contracts - and I suspect that even 6 figures wouldn't make it worth it).
To conclude, I don't think your contra-anecdotes are enough to counter the position that assuming Gregorian is 'good enough' in the vast majority of cases (again, those few writing software for Mormon record keeping, or history journal analysis tools, or -yes- software for Iranian state systems, probably know so much about dates and times that they don't need '100 things' lists to know what to look out for).
This is useful, but technically false. Go tour graveyards around Boston. You'll find stones with two death dates on them from the mid-1700's (most of the US changed in 1752).
https://docs.oracle.com/javase/7/docs/api/java/util/Gregoria...
http://en.wikipedia.org/wiki/Eucla,_Western_Australia#Time_z...
The standard says: "The implementation of ECMAScript should not try to determine whether the exact time was subject to daylight saving time, but just whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time. This avoids complications such as taking into account the years that the locale observed daylight saving time year round."
In Spidermonkey, at least, it mapped current years onto prior years where the current day falls on the same day of the week.
edit: Spidermonkey bug I filed a long time ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1029923
On a side note, the title reminds me of a similarly interesting bug in OpenOffice.org: https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619
Except for you know, when it's still light at 7.30pm.
I like light evenings in the summer and am prepared to accept a little complexity as a tradeoff.
And didn't Australia do some last minute DST nonsense like a Latam country, versus planning far ahead?
It's rather like redefining the metre so that everyone is 2 metres tall - you're adding a lot of complexity for not a lot of consistency.
For example, in Melbourne, Australia, in the winter it will be dark by around 5:30pm. In the summer it gets dark by around 8:30pm. I like having inconsistent sunrise and sunset times (e.g. extra daylight time in the evenings in the summer).
Neither do I think daylight savings extends the amount of daylight. What it does is shift the typical working day so that by the end of it, there are still a few more hours of daylight left. That's what I like about.
It's not about going out, it's just nice still having a few hours of daylight in the early evenings after I've finished work.
I guess if a business is in the past where screwing around with the clocks at nighttime is unnoticeable, maybe it's an acceptable solution. But in 2015, DST seems as bad as leap seconds. Perhaps even worse.
John is a factory worker who can't afford a car, so he takes the bus to work. Does the bus schedule allow him to come in and leave an hour early?
Frank and his wife both share a car; Frank has to drop his wife off on his way to work. Can Frank's wife come into work an hour early as well, or does she have to spend 9 hours at work and Frank has to wait an hour before he can pick her up? How about Jerry, who gets dropped off by his friend Lloyd because Lloyd has to drive that way anyways and doesn't mind doing Jerry the favour? Does Lloyd have to start running his daily errands earlier, now?
And don't forget that whatever solution you engineer for all of these people, it can't be too permanent, because we're just going to reverse it in a few months. And then re-reverse it later on.
We are talking about a person who is using his personal preferences to dictate the life patterns of everyone in the world and characterizes it as a "trade-off".
It's maybe a selfish reason, just to get a little more daylight in the evening, but I'm not the only person who thinks this way.
If it's only me moving my schedule, then I'm getting up an hour earlier, eating breakfast an hour earlier, starting work an hour earlier, getting hungry for lunch an hour earlier, finishing work an hour earlier, going to sleep an hour earlier etc.
It puts me out of sync with everyone else around me. Yes I'd get used to it eventually as would people around me and then I'd switch back half a year later.
If however the clock moves, then everyone around me is moving their schedule too, and we are in sync.
Works for everybody.
If someone built an alarm clock with a GPS receiver that used the equation of time to calculate apparent solar time, mean solar time, and civil time from GPS time, and if it allowed the user to set the alarm as an offset from local sunrise, noon, or sunset, would anyone besides myself buy it?
I think if more timepieces were more informative about how much difference there is between civil time and mean solar time, people would be less tolerant of daylight savings time. But those timepieces would also have to handle all the time zones plus the multitude of stupid rules different civil jurisdictions use to calculate DST. Hopefully, the wrist-mount computers emerging onto the market will make it possible to create "DST howling outrage generator" applications.
That's correct, and most people choose times that are roughly in sync with the people around them. Waking up an hour earlier is less useful if the gym isn't open an hour earlier, or your favourite breakfast stall isn't open an hour earlier etc.
Some people work 2nd or 3rd shift, and a few of them even do it by choice. If you think moving things around by one hour is difficult, try shifting them eight hours. Those people still manage, though they often acquire sleep-related health problems and have to deal with more inconveniences in their daily life.
Quite a few years ago I was working in WA on a system that frequently aggregated data from servers located in different states when they decided to try daylight savings. From memory it was decided by the WA state government that the state would adopt daylight savings on a trial basis, try it for a year or two, then consider if we wanted to keep it.
For programmers it was pretty much the worst possible solution. Have it or don't have it, don't force us to make sure everything supported having daylight savings in WA and also require the ability to possibly turn it off again in the relatively near future.
Getting annoyed just thinking about it...
Also remember at one point NZ was having a potential power shortage caused by a drought[1]. Some senior government officials were suggesting bringing forward the start of daylight saving by a month with around 2 weeks notice.[2]
[1] - NZ gets most of it's power from Hydro
[2] - The jury is still out on if daylight savings saves power, especially since different places have low/high aircon usage.
At best it's a wash. People all think that domestic lighting is a big power user, but in reality it's things like commercial shopping centres and office buildings that really suck down the juice. And typically those are run on a timer, so the pattern doesn't change (even if the timer is adjusted, the lights,ac and services are on for a fixed period of time).
Any savings for people having their lights off for 60 minutes less is swamped by people switching their AC on when they get home an hour earlier.
I still support DST as a quality of life thing, though.
I was amused at this comment, since i always dread the week or so after transitioning. Invariably my biological clock is screwed up and i'm something of a zombie in the morning at work and the later evening at parties.
The people who die each week after DST changes don't have much of an improved quality of life.
The clock should never change; if people want a different schedule then they should work 0700-1600 or 0600-1500 or whatever.
WA Govt was very keen on us voting for it, and assumed that with a trial we would get used to it and it would pass. As it turns out, that time it was rejected by the biggest margin so far.
We eventually realized that the unittest will only fail after work hours, at which usually no one is around to start tests. It turns out the test will fail during 6PM - midnight because of an UTC issue.
Now that is the sort of thing that drives programmers nuts.
I have an app where users are running it while crossing time zones. :-(
Every time we switched to or from DST there were a couple of outliers that got caught. We'd update the tables to handle the case correctly next time, but would miss something else, if the change didn't break something else completely.
Why do you have unit tests hitting outside services? If you have developed service clients that need to be unit tested, you should have mock services for them to run against locally so that your unit tests aren't going down every time there's a remote service failure. They don't need to be full blown services, but they should receive the request and respond with the expected result the service would give when hit by the client.
If your clients are generated by the remote service [i.e. by WSDL], then you shouldn't theoretically need to test those as they're generated by the third party - so you should be unit testing against mock clients.
I'd argue that integration tests with real world 3rd party services should be handled by some reporting system on your build pipeline somewhere and your ops team should be investigating that failure, you shouldn't need to be running them locally on your dev machine.
Hard coded dates not taking into account timezone and daylight saving? Been there, done that. This week the time was AEST-DS (Daylight saving) and is now AEST (finished daylight saving) [0]
[0] For example: Melbourne AEST: Australian Eastern Standard Time == GMT +10Hrs
DS AEST-1 hour when daylight saving is declared. When Daylight saving finishes, DS is AEST+1 hour or AEST again.
Test was that at $1/day, now+1 month would be $31. Wrote the test on the 30th of March, so found out about it the next day.
If it had been written on the 1st of March, wouldn't have found out about it for a month.