So, I have a beef. I'll lay it out for you with a hypothetical situation. (Perhaps only partly hypothetical...)
You develop an application for a customer in a different time zone. Let's say a 'quite' different timezone. While they are conducting UAT (user acceptance testing) they mention that the Date Recorded of a document doesn't seem to be in their timezone. You look at the code and realize you are setting the field with @Now.
You implement a fix on that field to adjust @Now to their timezone. Something like @Adjust(@Now;0;0;0;ClientTimeZone;0;0). Simple fix and the client's happy.
Now, do you want to be a 'Good Developer'?
Then take a good look at the system, and everywhere else in the workflow that you're using @Now, adjust them too...
If you merely want to be mediocre and the subject of humiliation by your support department? Just leave them alone. No one will notice the time difference between GMT-5 and GMT+11, right?
It is important to teach young employees not to just "do what was asked" but to think about what is *really needed*. It is a valuable distinction, and makes a more valuable employee - in any department (not just programming).ReplyDelete
If, however, you're having this problem with a more experienced employee, the mindset may be entrenched. I pity you.