Andrew Zeneski wrote:
I disagree. Personally I like methods with optional arguments,
especially when these arguments aren't really necessary. When you do
not pass the extra arguments, the assumption should be that you get the
defaults (default Locale and default TimeZone) which is fine.
But there is the problem - those arguments ARE really necessary, and getting
the defaults is NOT fine.
A properly coded date/time calculation will take into account a user's locale and time zone. If a
developer chooses to use date/time calculations based on defaults, then the user is presented with
two sets of date/time data.
If I add 12 hours to noon today, I would expect the resulting time to be noon tomorrow. Your method
could produce noon tomorrow, or 11 am, or 1 pm - there is no way of knowing the outcome.
Not too long ago the Workeffort calendar was useless - it was inaccurate and buggy. Why? Because it
made the same assumptions that you are making. I fixed the Workeffort calendar by following the
guidelines presented by Sun and IBM - two companies that understand internationalization. My
position in this thread is based upon what I learned while researching the subject, what I learned
from writing my own calendar application, and ultimately taking what I learned and using it to fix
the Workeffort calendar.
-Adrian
