Do I need to get client's actual timezone or can I assume they are all in the EST timezone? (US-only web application)

I have a question about dealing with date & time in my web application. The application will sell monthly subscriptions. It shows dates only when clients buy and cancel subscriptions. Clients can buy additional services in the middle of the month. Application calculates a pro-rata to charge the client until his anniversary date.

I will store dates/times in UTC. It is only for US clients.

I am considering the following options and I would love to get feedback from more experienced developers:

1 - always present dates in EST. I can include a small caption explaining that all subscriptions uses EST. This would be simple as I would not have to deal with clients' timezones. However I am not so sure if clients would be put off by this. Any thoughts?

2 - always present dates in EDT. This would probably not work very well as it would be harder to explain the reason for using it. However I believe it would be simpler to process than EST.

3 - ask for client's timezone information when he signs up for the service and use that information. I don't think this would add too much complication, however I would have to offer them an option to change timezones and I would have to decide what to do with existing subscriptions when there is a change in timezone. If I go with this option I would ask the client to pick the timezone from a drop-down list.

4 - ask for client's location (City and State) and calculate the timezone myself.

5 - try to guess client's timezone based on his IP or another method (ideas???).

Options 3, 4 and 5 would probably be the most user-friendly. Option 1 seems to be the most straightforward to implement.

Sorry for the long post. If you took the time to read it, would you mind taking a little more time and sharing your thoughts and experience?

Thank you.

UPDATE 1 - 9/3/2011 - 17:08 MST

Just found out that PayPal records transactions using PDT and shows them to the client using the client's local timezone they setup when they signed up with PayPal.

I am now inclined to:

1 - show current date using PDT (to align with PayPal) - I will probably change the code to show date & time PDT. Currently I am only showing the date. I believe it will be clearer to the client if I also show the time.

2 - I will not show the anniversary date. I will let PayPal handle that. I will simply state that it is a monthly billing.

3 - When clients add a new service I will calculate the pro-rata using PDT and I will give them a three day grace period to account for timezone differences (thanks to Robert Levy below for suggesting it) and PayPal processing (I don't want to charge them a pro-rata amount if they are only a couple of days from their regular monthly charges).

Any thoughts?

Update 2 - 9/3/2011 - 21:01 MST

Just a quick update. After further research I found out that PayPal does send me a transaction date back. I am not going to show any dates until the client pays at Pay开发者_JS百科Pal and I receive confirmation. I will show PayPal's transaction date in the client's receipt.

Sounds like a plan. What do you think?

Just add a grace period of 24 hours from UTC. Easy to code, no extra UI, and unlikely to upset any customers.