Encore Requests: Last-Modification Date

[Denkster]

I'd like to emphasize that date format is country dependent

You are absolutely right!
'yyyy-mm-dd' (or rather: 'jjjj-mm-dd' ) is not so strange in the Netherlands, however, dd-mm-jjjj (short), or dd monthname jjjj (long) is most common.

That is why serious applications have at least these alternatives:

• OS date format
  
  • long
  • short
• application date format
  
  • long
  • short

[polarbreeze]

Why wouldn't it just use the format the user has selected in the OS?

[matt-olddev]

Why wouldn't it just use the format the user has selected in the OS?

thats what should be happening and we hope to get this working when we release localized versions

[Doug Kerr]

Why wouldn't it just use the format the user has selected in the OS?

thats what should be happening and we hope to get this working when we release localized versions

Excellent.

But it should be working in the "non-localized" version as well. The user does the basic localization for date format in the O/S.

I would think that any form of Encore should use what the O/S passes as the adopted "short date" form and just not try and "improve" on it.

Doug

[Denkster]

it should be working in the "non-localized" version as well. The user does the basic localization for date format in the O/S.

I would think that any form of Encore should use what the O/S passes as the adopted "short date" form and just not try and "improve" on it.

Exactly!
I wouldn't know how to localize a program function anyway..

Eveline

[matt-olddev]

But it should be working in the "non-localized" version as well.

of course. i never said anything to the contrary

[Doug Kerr]

Hi, A,

Doug, I'm not sure this only-one-level localization (by the OS) is 100% ok.

I didn't mean to imply that following the O/S choice should be the best Encore could do. It should be the minimum.

What I was questioning (perhaps not effectively) was the suggestion that Encore would take on that capability through the development of localized versions.

But I turns out that such was never said.

Silly me. C'est une langue difficile, l'anglais.

Doug

[Doug Kerr]

But it should be working in the "non-localized" version as well.

of course. i never said anything to the contrary

Oh, sorry.

Doug

[Doug Kerr]

But it should be working in the "non-localized" version as well.

of course. i never said anything to the contrary

So, did you mean that Encore's ability to use the short date format set in the O/S in a straightforward way would emerge first in localized versions, and then later in the "general" version?

Thanks.

Doug

[matt-olddev]

So, did you mean that Encore's ability to use the short date format set in the O/S in a straightforward way would emerge first in localized versions, and then later in the "general" version?

Doug

there are a number of things like dates and paper size and things that Encore should be getting for defaults from the OS, but calling this the "american english" version we are able to let them slide but will need to deal with when we are localizing.

i do like the suggestion to just make the default date format match the OS and let users pick others if they want. page size would of course be this way.

[Doug Kerr]

Hi, Matt,

So, did you mean that Encore's ability to use the short date format set in the O/S in a straightforward way would emerge first in localized versions, and then later in the "general" version?

there are a number of things like dates and paper size and things that Encore should be getting for defaults from the OS, but calling this the "american english" version we are able to let them slide but will need to deal with when we are localizing.

I don't agree that my use of the format YYYY.MM.DD (set in the O/S) is so "foreign" that I shouldn't be able to expect it to be supported by the "American English" version.

i do like the suggestion to just make the default date format match the OS and let users pick others if they want. page size would of course be this way.

Yes, that would be a great starting point.

Presently, for the date, we actually have that, but screwed up. If the format set in the O/S is YYYY.MM.DD ("yyyy.MM.dd", in the Windows date format syntax), Encore adopts a "tampered-with" version of it as its default. Its the "tampering with" to which I object.

The tampered takes only the last two digits of the year and then applies leading zero suppression to that. It may not even be representable in the Windows date format syntax. (The description of that is so ambiguous I can't be sure.) It may be that it is "y.MM.dd".

Thus, for today's date, in my system, the token "#D" in Encore returns "9.07.16".

Doug

[Doug Kerr]

For what it's worth, it appears that the date format syntax in Windows XP works this way for numeric returns:

"yyyy" = returns entire year (four digits). [One is tempted to ask, "does that have leading zero suppression?", but in fact the range of the data code does not allow for a year like" 960" that would actually bring that issue to bear.]

"yyy" = treated like "yyyy" (see above).

"yy" = returns last two digits of the year (no leading zero suppression)

"y" = returns last two digits of the year, but with leading zero suppression (minimum return: units digit, even if 0)

"MM " = returns month number as two digits.

"M " = returns month number as two digits, but with leading zero suppression (minimum return: units digit, even if 0).

[Note: significance of upper case letter "M" is only that "m" is used in format codes for minutes.]

"dd " = returns day number as two digits.

"d" = returns month number as two digits, but with leading zero suppression (minimum return: units digit, even if 0).

Doug