performing Date manipulation in Batch has many flaws:
First: a string has to be parsed- usually from date /t or %date%. Why is this a problem? Because exactly what and how it is parsed depends entirely on regional options, none of which can even be inferred. for example- how do you know wether "Wed 12/01/2009" is January 12th (DD/MM/YYYY) or December 1st? (MM/DD/YYYY)? Logically- we can see that it is the first option, since January 12th 2009 was a Monday. But there is no way to acquire this information programmatically via batch code.
Visual Basic Script uses the OLE automation Variant Date manipulation Functions to perform it's Date manipulation. These routines "know" what the systems regional settings are and know how to parse dates. Date is, a different variant Subtype (and in full blown VB can be used as a explicit type as well) and for good reason. Handling Dates as strings is playing with fire; you simply cannot predict for every possible arrangement of time and date information. If the regional options are set to display as "DD/HH/MM/YYYY/SS" (day/Hour/Minute/Year/Second) then the user should *censored* well be able to input their PREFERRED entry style into scripts that accept date entry; that's what the regional settings are for. There should be no requirement to "enter in this specific format" because "this specific format" should be the bloody regional settings format as set by the USER for purposes of DATE ENTRY.
Additionally, I know why Salmon Trout, at least, would be so animate about this type of thing. the UK uses a different date format by default, and every time one of us USians decides that the default North American format is "good enough" for a batch it's like a little slap in the face, especially when tools such as VBScript are so widely available that solve the issue entirely. And really- it doesn't matter the context- there is NO excuse for ignoring the OS preferences as set by the user.
A analogous situation could be seen with batch when it was only a "pure DOS" type solution, without command extensions. It could NOT do arithmetic at all.
Did people write batch files to perform arithmetic and parse date strings? No. Because it was bloody hard and not worth the time; when people needed to do math like this they ALWAYS resorted to another solution. This should be the case for performing date manipulation with Batch. If there will be any sort of deployment of a batch file across a company or especially in separate countries, the "good enough" string parsing solutions in batch will not be acceptable, and something else will need to be devised. How much batch code will be necessary simply to properly parse a date string using regional options? None- the problem is intractable in batch code because there is no way to acquire the regional format and there is surely no way to properly use that string (if it is even acquirable) to parse out the components of a date /t output.
The best compromise solution would be to write a VBScript to perform generic date manipulations and ignore performing such operations in batch at all.
