Here's the problem: the EU and the US do not turn DST on and off at the same time; this March, there was a three weeks' difference between these events.
Here's what happens during this period. Let's say you have an event every day at the same time and, since you are based in the US, you are going to adjust times using the US DST.
Day (2001) United States Europe United Kingdom Global Time delta
March 5th EST 1500 CET 2100 GMT 2000 GMT 2000 +23h
March 6th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 7th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 26th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 27th EDT 1500 CEST 2100 BST 2000 GMT 1900 +24h
Let's analyze all possibilities:
If you display the time in a global timezone and call it UTC, which feels like the right thing to do, you're going to confuse your American customers, who are going to see different UTC times (yesterday 8pm, today 7pm) for the same wall clock time (yesterday 3pm, today 3pm again), and then your EU based customers, who don't see the posted time clock change and yet must change their wall clock event time.
If you display the time in a global timezone and call it GMT, in addition to confusing US customers you'll also confuse UK customers who switch from GMT to BST. It is counterintuitive to understand that EDT 1500 and EST 1400 are the same moment in time; now translate that into BST/GMT (with the additional problem that you're not going to be showing BST times in any part of the site).
If you display the timezone in an EU timezone (I used CET/CEST to avoid GMT/UTC confusion), that's obviously going to be super confusing to your US customers, who see the event time switch back and forth twice and yet experience no wall clock time change themselves. While your US customers may be prepared to the first switch (after all they have to change their wall clocks on the same day), they'll be surprised by the latter.
If you display the timezone in the US timezone (like EST/EDT), you're going to have the exact situation explained above, but mirrored!
This seems like an hopeless situation! Here's how I came to address it after four years of going through this rigmarole (twice a year, obviously): "make up a timezone."
I am in exactly the situation pictured above, so I made up "NYT" (New York Timezone) so that I could write "1500 NYT" to mean "3pm in whatever timezone it is New York happens to be using."
This has the advantage that, so long as the user knows that the DST waltzer is happening, he has a very simple way of converting back and forth to their own timezone: google "time in new york" to see what time it is in NY, then work it out from there. You can even get fancy and use geolocation-based services such as time.is/15:00_in_New_York.
Note that, while you could use timezone abbreviation names in time.is, I urge you not to, for they are pretty confused about it all themselves: EST has the same time as EDT‽
You can notify users about DST with some short blurb, linking to an appropriate time conversion webservice to help people out. Ideally all timestamps should have an option to be converted into local time.
When all's said and done, you should realize I've been ignoring the elephant in the room all time long, and that's the "countdown" solution you have already implemented. There's nothing confusing about "in 1 day 2 hours 45 minutes 47 seconds" (and if you believe you don't need that much precision you might want to think again).
Sure, in my experience I never had the luxury of anything that wasn't static text, so I had to handle the incredible mess pictured above (and that's only the beginning of it! How about the southern emisphere, that does DST backwards?), but for your use case it sounds like the solution with the least potential for confusion. You might get two threads a year asking about "in 23 hours" and "in 25 hours" events while it normally counts down from "in 24 hours", but that's it.