>>>>Good point, and now for the lazy ones
>>>>
>>>>Create the function my_ctod as above
>>>>
>>>>Now use your global include file and add
>>>>

>>>>#DEFINE CTOD my_ctod
>>>>

>>>>
>>>>Precompiler replaces CTOD with my_ctod. Done. No replace anywhere else.
>>>
>>>Hi Lutz.
>>>
>>>Your solution might work, but my argument it would be confusing to a future maintenance developer who sees input to what seems like CTOD() using parameters inconsistent with the expectations of a British date.
>>>
>>>I would choose to manually replace each instance (or programmatically do so in this case) to keep it clear.
>>>
>>
>>I agree completely with Rick in this regard. Those backdoor tricks only increase technical debt and will for sure bite you back at one time.
>>
>>Even better try to upgrade the affected data with non-ambigous values if possible.
>>
>>"Always code for the maintener:
>>Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live."
>>
>>http://wiki.c2.com/?CodeForTheMaintainer
>
>While I see a certin point. I do not agree.
>
>- I do not get paid for. I get paid for the hour I can sell. If my hour for such a fix is 10 minutes I get the same as if this is a 120 min hour. 110 minutes I can spend with something less boring.
>Customer satisfaction is the same. I get paid for the knowledgde of fast work - and for beeing rested on the next hickup.
>
>- Look what other langs do with objects overloading, look for eventbinding. This all adds up stuff you don't see in the code straight - I have no problem with #DEFINE. It's not hidden, it's no backdoor. The maintainer not knowing the header files firsthand does a bad job.
>
>- All the arguments pro maintainer have only one goal. Do make the programmer interchangeable like a leaf of bread. Neoliberalism at it's finest.

I think there are different situations where either one or the other could apply. But this case teaches a valuable lesson about software design and management.

For instance just last week, we had three people try to chase an error for over three hours which was caused by a copy paste issue that was done 5 years ago. The client tried for a considerable time to create an export file for a financial transaction import which showed incorrect information. We have sent him several updates of the code, but nothing worked. Aggravation everywhere, management in panic.

Turns out a programmer saved 15 minutes time by just copying an unsuspecting line into a dubious place, which seemed to be not a big deal back then (because software requirements nevery change?)

So we lost more than 10 hours productive work, not to speak about the client's loss. We could not charge for finding the error obviously. The debt had to be paid at one time, but including a very high interest.

In the case of the date format, the error is not happening now, it happend a long time ago, when a programmer decided to use a character date format that is not portable to other local settings. It is a technical debt that exsists and now got detected. The debt may be paid now or later. I believe a considerable time was already spent at this point in time, so time has already been lost may not be chargeable.

The question is to create new debt, or to pay the debt now. The first option will very likey result in postponing the payment. It is like Italy with their new budget.

The most common solution to this problem: Let the programmer work overtime without additional (or very little) payment.