When I open the graphics window (to see where I am in the process), it shows a model date 02/09/1993.

Now what does this date mean - have I recently finished a year (Feb 09 1993), or am I going to finish a year soon (02 Sept 1993)?

The format I would like to see there is the date format I have specified for Windows and all applications to use (Control Panel | Regional Options).

Wouldn\'t that make much more sense for everyone?

Thank you :)

The project is English, the models come from the British (UK) Met Office, and so the dates are British format: day / month / year.

The dates are not derived from the OS date system.
To do so would confuse the issue when physicsts start to use the models.

Personally I think it\'s more logical for any date or time format to go from largest unit to smallest (eg days;hours;minutes;seconds) or from smallest to largest. The CPDN model date format does do this.

---

Cpdn news

The project is English, the models come from the British (UK) Met Office, and so the dates are British format: day / month / year.

It is, indeed. My model date now shows 27/02/1996

The dates are not derived from the OS date system.
To do so would confuse the issue when physicsts start to use the models.

What I mean is to display it in my Windows specified form - in my case I would want to see 1996-02-27. How the dates are kept internally is not my concern.

Personally I think it\'s more logical for any date or time format to go from largest unit to smallest (eg days;hours;minutes;seconds) or from smallest to largest. The CPDN model date format does do this.

Exactly; I would very much more like to see 1993-09-02 than the confusing 02/09/1993 (I don\'t mind the dashes or slashes).

There is an ISO standard for this (ISO 8601), which any sensible programmer will use internally or - I would suggest - in filenames. Though the fact has escaped many programmers, human beings are not computers, and the \'locale\' formats should be presented to the \'wet-ware\': pwillener should not be expected to parse a British date, any more than I should receive a decimal comma instead of a decimal point on my petrol receipt. For the busy programmer, ISO 8601 is a good substitute for the correct locale, since it follows the largest-to-smallest rule - which will eliminate most ambiguities.

BOINC itself is good at this sort of thing.