date and cmd compatibility

[NetMage]

TCC returns different results for the date/t and %date% commands when the region is default (in US) and the format is m/d/yyyy. Can an option be added or a change made to regain cmd compatibility?

 

[Steve Fabian]

Click on the word "feedback" on the left margin to request additional features.

 

[JohnQSmith]

I pointed this out about 2 years ago. http://jpsoft.com/forums/threads/date-t.4064/

 

[NetMage]

@Steve,

I'm not sure I consider cmd compatibility an additional feature.

 

[Steve Fabian]

If it is not an additional feature (your terse wording required reading your post thrice), you must consider the issue a BUG - an unexpected change from earlier behavior. So signalling emphasizes the nature of the event.

 

[drwtsn32]

agreed.... i wish Take Command was compatible with CMD in this regard. As it stands I have to use two methods in my batch file that would otherwise be command processor independent:


:: this works in CMD and would work in TCC if month/day were zero padded
set _archive=%_folder%\%date:~-4%-%date:~4,2%.7z

:: this is needed for TCC
if %@eval[0] == 0 (
set _archive=%_folder%\%_year%-%@format[02,%_month].7z
)

 

[rconn]

If you run DATE /T and %DATE% on 100 systems running CMD, you'll get about 99 different answers, because it's dependent on your locale and how you've defined your date/time display. So there isn't really any concept of "compatibility" here, because CMD on one system will not be compatible with CMD on another. (Or even on the same system if you write a batch file and then alter any of the defaults.)

The only difference between TCC and CMD in the DATE /T output is that CMD puts a leading 0 on the month, which doesn't seem either particularly readable or useful. CMD puts a leading (language-specific) day of the week on the %date% format (and a leading 0 on the month), which also doesn't seem especially useful.

Why do you think emulating the CMD behavior (and breaking existing TCC behavior) is important?

 

[Steve Fabian]

If you used ISO8601 you not only would use an international standard date style, but also one which can be sorted and compared as strings and provide event timing order. To get this in CMD you must use the Regional and Language Options in Control Panel; it will also set the default formats for TCC (and did for 4nt).

 

[Charles Dye]

My take, for whatever it's worth: %DATE% exists only for compatibility with CMD.EXE batch files — it's otherwise pointless and redundant — so it makes sense that it should emulate CMD.EXE as closely as possible, even to the leading zero. DATE /T is more a convenience for interactive use at the prompt, so there's far less need for it to exactly match CMD.EXE's behavior. I think the present, leading-zero-suppressed format is more esthetically pleasing; but of course others might disagree about that.

 

[rconn]

My take, for whatever it's worth: %DATE% exists only for compatibility with CMD.EXE batch files — it's otherwise pointless and redundant — so it makes sense that it should emulate CMD.EXE as closely as possible, even to the leading zero. DATE /T is more a convenience for interactive use at the prompt, so there's far less need for it to exactly match CMD.EXE's behavior. I think the present, leading-zero-suppressed format is more esthetically pleasing; but of course others might disagree about that.

The interesting point here is that TCC is compatible with Windows, and CMD isn't. TCC uses the Windows GetDateFormat API to display the date in the default locale format; CMD uses its own formatting (i.e., not what the locale or the user specified). Is that a good thing?

 

[Charles Dye]

CMD uses its own formatting (i.e., not what the locale or the user specified). Is that a good thing?

CMD.EXE is weird. It looks as if it's using DATE_SHORTDATE and then somehow misinterpreting the format string. MM gives a two-digit month as specified. M also gives a two-digit month, but causes the day of the week to be prepended. I don't know how Microsoft managed that....