There are several problems:
You are basing which rule to use on the current date, rather than on the date provided in your input. You should change that for sure.
If I pass a value such as 2013-03-10 02:30, your function will assume that it was EDT, but in reality that time was invalid and should not exist in your data. You should probably raise an error.
If I pass a value such as 2013-11-03 01:30, your function will assume that it was EDT, but in reality it might have been in either EDT or EST. You would need to have stored either an offset or a dst flag to disambiguate. If it's not in the data, you have no choice but to assume one or the other.
This function doesn't account for dates before 1987, which also had a DST rule change in the United States. If you have data from before then, you should account for that as well.
Other than that, it looks fine. Still, the points in the comments are correct. This will only work for this one time zone, and you have no guarantees that the rules for this time zone won't change in the future. I recommend you use convert your data to use UTC going forward. You could use this function for the conversion if you like, or you could just as easily do it in application-level code.
Oh, and one other thing. "Eastern Standard Time" or "EST" literally means UTC-5 without regard to daylight saving time at all. Just like "Eastern Daylight Time" or "EDT" always means UTC-4. I assume that you meant to say that your data is in "Eastern Time" in your question, which accommodates both.
If you actually meant EST, then your job is a lot simpler - just add 5 hours and call it done. I bring this up because there are indeed scenarios where data is recorded without respect to daylight saving time. (I believe there are some use cases in the financial sector that work like that.)