All dates are stored as YYYY/MM/DD. You can reformat them any way you want by grabbing the pieces and stringing them together in whatever order you want.

Without leading zeroes - 19/6/2003

var vFDate as String

vFDate = @Str(@DOM(MyDate)) + "/" + @Str(@Month(MyDate)) + "/" + @Str(@Year(MyDate)) 

With leading zeroes - 19/06/2003

var vFDate as String

vFDate = @Text(2 - @Len(@Str(@DOM(MyDate))), "0") + @Str(@DOM(MyDate)) + "/" + @Text(2 - @Len(@Str(@Month(MyDate))), "0") + @Str(@Month(MyDate)) + "/" + @Str(@Year(MyDate)) 

Then feed the variable to PrintString:
PrintString(vFDate, ...)

Quote:


Carl,

Your version isn't type-safe. It depends on automagically converting the date to a string. This is often not the case. In SBasic, dates are dates, not strings pretending to be dates. SBasic will try to make your way work, and will often succeed, but its best not to depend on implied type conversions. If you've got a date, it's best to treat it like a date.

The danger in treating a date (or any non-string type) as string is that you are depending on an internal coincidence of implementation that can change without warning. It is not part of the language specification that dates are presented as strings - thus it can change without warning in future releases.

We will make sure that @year() will always work. But there is no guarantee that grabbing the first four characters of a date (treated like a string, but not actually converted) will.

If you want to treat any field type as a different field type, always convert it to the needed type.

Quote:


It only works well in this version because Mark and Andreas, knowing that Q&Aers often treat dates as strings, rather than using the date access functions, like @Year, went to some effort to try to turn the date back into a string under the hood when someone tries to use String functions on it. They may not always be able to protect you from these kinds of issues in the future.

Thanks a lot guys - all is becoming clear to me ......slowly