Date formatting strange?

[molly]

As you can see in Molly's post:

I have just realized that you are Molly. 

No problem Zoran.

You have no idea how many times we confuse one another between ourselves. It becomes more difficult when mirrors are involved (And how many of them). 

The real question is: who of us is the one with the wrong assumption and who the one with the question with the obvious answer 

But, you are right. You're the one who also started this questions of my, so kudo's for that to you as well.

[molly]

Thanks, but now quite confused by Molly and Phil.

That was not the intention, sorry. As you might have realized i was confused about something as well (or at least made the wrong assumption).

...to every Unit where I use a call the includes a predefined and Formated string, like Date etc?

No.

If you are on Linux then you can use unit clocale and, that unit needs to be 'loaded' once. Preferably at the first opportunity possible.

Would you do it later then your program might (unknowingly) already have been using a format function that uses 'uninitialized' format settings that don't correspond with your systems locale settings.

So, please lighten up with th the "rtfm."

I am more than happy to add more to the rtfm part but it is all logic there.

I made the wrong assumption in believing that the default format settings that are used by the date and time conversion routines are initialized by user locale settings automatically. I thought this was done automatically for each platform.

It turns out this in only the case for windows. You need to use unit clocale to make that happen for *nix platforms.

Not doing so will result in some 'random' default values that Free Pascal uses. Note the inconsistency there so that you can never rely on something because it depends on the (target) platform.

As of the implications of things:

Suppose you change one of the global locale settings of FPC to your likings. That is in theory perfectly ok to do. But, what happens when another component also rely on that same locale setting that you've just changed ?

It will act as you instructed. And that is also perfectly ok but, only for those cases where the component actually took the correct approach and not use other hard-coded settings of it's own.

You might think/believe that is not often the case but, if you take a look around you see many (bad) examples of projects assuming that date/time settings is a hard-coded setting. When using the default conversion routines from string to datetime and vise-verse, then things can go horribly wrong and user is presented with a "invalid date time format" message while the project insist on f.e. the dd/mm/yyy format.

That is why i made such a example with a horrible format string for you in the first place.

Never will anyone use dd*yyyy*mm format, until the day someone does and those relying on date/time format always to use slashes for separation or YYYY to be at the end of the date format string goes horribly wrong 

So, either you 'stick' to what the default user setting are by copying those settings from the underlying OS (as suggested by Zoran and Phil), or you allow user to change setting based on OS locale setting (not the default ones, but allow for the user to change into something more comfortable. Also provided by underlying OS settings) or... and this is important... you use temp settings for your own custom conversion.

Either you do that by providing the format parameters using your own format settings or provide a string which contain this setting (as i've shown in my example)

The reason i never am confronted by this myself is that in my projects i use my own custom settings (and corresponding date/time/currency conversion routines)  that user can change, and not rely on underlying OS settings (although i allow for user to copy from them from OS on request).

Is that perhaps more clear ?