Implicitly Yours

I recently presented at the Dallas Scala Enthusiasts meetup on implicits in Scala.

My presentation can be found here and the code can be found in the associated Github repo:

Here’s some sample code from the slides so this post looks interesting:

implicit val n: Int = 5

def add(x: Int)(implicit y: Int) = x + y

add(5) // takes n from the current scope
add(5) (1) //can always call explicitly

I had a lot of fun making this presentation and switching back and forth between slides and code.  I really liked making the slides in markdown with Remark.js and hosting the slides in the same repo as the code.

I was told there would be not math – automotive edition

The highest insurance deductible is not the way to go.

My Tacoma on the left, not as much back seat as some trucks

I recently had to get a car that can accept car seats and had the accompanying excitement of getting new insurance.

IMG_4417.JPG
In real life I'm not quite as pale.

There are all sorts of options in there and some are mandatory.  The place where I feel I have the most control over my destiny is the comprehensive and collision.  With all of the liability options you are required to get a certain level and your assets you don’t want to lose in a law suit help you determine how much liability protection you want to purchase.  Collision and comprehensive are entirely up to you.  You don’t even need to buy them if you don’t have a loan.  The question is how much do you want to pay now vs how much do you want to pay later if you make a claim.  Like most decisions in life I made a spread sheet for it.

Conventional wisdom is that the higher you put your deductible the lower your premium and the more you save.  If you factor in the deductible cost when you make a claim the lower premium might not be worth it depending on how long you go between accidents.  It all sounds reasonable but it’s not useful until you put some numbers down.

For the new dad-mobile I went online to get insurance.  It would be great if they would just tell you the cost for each deductible at once, but life isn’t so easy and I had to click through the menu a bunch of times to get the following prices for the available deductible ranges for “comprehensive” coverage.  This covers non-collision things like hail, deer, burglary etc.

Comprehensive:

Deductible 6-month premium
0 65.33
50 57.52
100 52.79
200 46.20
250 43.54
500 34.06
1000 27.17

Your total cost for a time frame is going to be the deductible plus the premiums paid for that time.  So if you go 5 years then pay a $500 deductible you will have paid 2*$34.06 for 5 years plus $500.  To make the graph easier to read I then divide by the number of years (otherwise you get a bunch of straight lines with slightly different slopes).  In pretty chart form it looks like this:

Some interesting notes:

  • Your cheapest option for a time frame is the lowest line for that year.  You may be better off paying a higher premium for the lower deductible.
  • This is only useful if you admit that you will make a claim sometime.
  • My insurance company offers some guidance: 65% of their members choose $500 comprehensive deductible.
  • The $500 deductible isn’t the cheapest option unless you go at least 13 years without making a claim, few people keep their cars that long.
  • The $1000 deductible isn’t the cheapest option until 40 years out.  That long of a time frame is hardly even relevant because your vehicle is either a $0 junker or $$$$$ collector’s item by that time.
  • This is only good till the first accident.  Your premium will probably change after a claim.  So don’t make an assumption that if you make a claim every year that $0 deductible is the way to go.
  • Your premium also changes when you don’t make a claim, but more gradually.
  • The value of your car changes over time, so if you are in the large time between claims camp it may change whether you decide to cover it at all.

I’ve been driving for 11 years now so I think I have a big enough sample to make a good decision.  I have made 2 non-collision claims in that time.  I had hail damage in 2003 and was burgled in 2010.  Both were freak occurrences and not predictable.  I had raised my deductible to the maximum $1000 to save money.  Unfortunately this was just before the 2010 burglary.

For the new car I chose $200 deductible which means I place my self at the 7-10 year range for another claim.  The numbers for collision were much different and I chose $500.  Changing the numbers relative to each other by just a few dollars drastically shift which option is the cheapest for a given time frame.

The numbers were surprising, I went in thinking that the longer you go without accidents the highest deductible would always be the cheapest overall.  This is sort of true, but not on the scale of car ownership.

Do you think that most people choose the $500 deductible because

  1. They over estimate how long they will go without making a claim or
  2. They didn’t take the time to get a bunch of quotes and crunch the numbers?

 

Steven Gangstead

Quick Fix: SQL datetime

Setup:

I was importing some records from system A to system B.  Both were using MS SQL 2008 databases.  In my stored procedure there is an insert … select … statement.

Problem:

It turns out that system A stores the date_time field for the record in UTC time and then the application displays it as local time (Central time zone in this case).  System B is less robust and assumes the date_time matches whatever the local server time is.  All users are shown records in server time, wherever the user may be located.  Depending on the setup this usually never happens.  Let’s just say I’m aware of the shortcomings of this method and I’ll leave out the cliche “if I had been in charge I would have …” comment.

This was brought to my attention by a customer who said that their system said the record occurred at August 1st at 1 PM, but the new system said it occurred August 1st at 6 PM.  This wasn’t acceptable because they needed the info to match to be sure they brought up the same record in both systems.

Fixed:

I didn’t want to hard code anything in my stored procedure like “subtract 5 hours” to convert UTC to local time.  This would work for 9 months out of the year, but when daylight savings time ends CST is -6 hours from UTC.  DST changes from year to year, and sometimes the congress changes it all together and I don’t want to build that complexity into a dumb stored procedure.

First, you can get the difference in hours between UTC and local time with this:

select datediff(hour,GETUTCDATE(),GETDATE())

Then you can use dateadd to add that offset when you are inserting from A to B:

insert into A.dbo.records
date_time
select
dateadd(hour,datediff(hour,GETUTCDATE(),GETDATE()),utc_recs.record_date) as date_time
from B.dbo.utc_records utc_recs

This is greatly stripped down of course to show just the salient point.  I hope this saves someone some time in the future.

Steven Gangstead

Note: The only site I had to consult was the msdn library on date and time functions.