date and cmd compatibility

Nov 18, 2009
19
0
#1
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?
 
May 26, 2008
492
3
#6
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

Administrator
Staff member
May 14, 2008
10,494
94
#7
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?
 
#8
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

Super Moderator
Staff member
May 20, 2008
3,571
46
Albuquerque, NM
prospero.unm.edu
#9
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

Administrator
Staff member
May 14, 2008
10,494
94
#10
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

Super Moderator
Staff member
May 20, 2008
3,571
46
Albuquerque, NM
prospero.unm.edu
#11
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....