>>>>But understand that Naoto has explained why you had the problem. In general, you should avoid any code that relies on knowing the date format. If you must depend on it, then you need to set it when you need it.
>>>>
>>>>Tamar
>>>
>>>Hi Tamar,
>>>
>>>just out of curiosity.
>>>How will one define a interface, let's say csv, and not define date format? I allways do something like
>>>field n use blabla type date in the form YYYY-MM-DD in the interface documentation and SET DATE for the import.
>>>If the import comes with DD.MM.YYYY it's like an alpha in a numeric field. Or would you parse each and every field? This could be a challenge - in time sense. :)
>>>
>>>
>>>Lutz
>>
>>I'd read the input as a string -- then I'd parse it (according to the specification) then check for validity of data before saving the data to the table. In the case of an error, then I'd usually try to give the user an option of what to do (either by a pre-selected action as one of the options for import, or to give interactive warning that allows user the action to take). In general, I'd do a SET DATE around the beginning of the program to set up the configuration globally, then leave it that way (unless the user decides to change it). Changing the setting on-the-fly for various tasks could give rise to situations where behavior might not be consistent -- say for example if you've got timer events firing that might use dates.
>
>So you would do that with 50000+ lines of a csv?

Is there a guarantee that the input will always be in the correct format? Would it be acceptable that if the input data didn't conform to the agreed-upon format, that you end up with invalid data in the data tables as a result? Would it be acceptable for the import to simply abort partway during the import?