Regional date settings

[JRL]

I'm having a significant issue with a script I wrote failing because the regional date settings on other computers are not the same as on mine. The exact issue is that I wrote a script to deal with dates in a mm/dd/yyyy format and I've found a computer with dates set to mm-dd-yy. This causes difficulty when the script parses the date to put it into a mmddyy format for an EDI flat file. Macro Scheduler and VBScript date function results are all influenced by the computer's Regional Date Settings.

I was thinking it might be nice to have a Macro Scheduler system variable that defined the date/time format used by the date/time functions. I really don't know enough about the subject to know whether that would be a good idea or even if it would be necessary.

There are a significant number of Macro Scheduler users who write code to be distributed to the public or otherwise to non-locked-down computers. How do you folks deal with Regional Date Settings discrepancies?

[Marcus Tettmar]

Not ALL Macro Scheduler and VBScript date function results are influenced by regional settings. GetDate is. But Year, Month and Day always get the same results regardless of regional settings and DatePart and TimePart are also format independent (as long as the format provided is a recognised date format). In other words, don't use functions like GetDate. Use Year, Month, Day or if using VBScript use similar functions or date formatting functions which do not depend on a specific format.

[JRL]

Thanks Marcus.

Yes... when I want today's date I always use Day>, Month> and Year> then construct the date in the format I desire. I can't think of the last time I used GetDate> in one of my scripts. My problem today is that I wrote a lengthy process to make sure parts ship the day before a weekend or holiday so I'm using DateDiff> and DateAdd> which both require LocalDate> which is contingent on Regional settings. Same issue if I use the similar functions from VBScript. The results are formatted to the date time settings on the computer running the program.

I did just discover the VBScript function called FormatDateTime. It looks like it could resolve my immediate problem. I'll also look at DatePart> which looks promising as well. But the question remains. What has everyone else been doing in this situation?

[Marcus Tettmar]

Right. Yes, DateDiff and DateAdd need the date in local settings. So you use DateLocal to PUT a date into local settings. THEN you can use DateDiff. And THEN you can use DatePart if you want to strip that date out and reformat it

DateLocal takes year, month and day part and returns a format that the local system understands. So you can then use that in any calcs, and then use DataPart if you want to get the bits out and make your own format again.

[JRL]

...then use DataPart if you want to get the bits out and make your own format again.

It appears that DatePart> uses the least characters (1 or 2) for the month and day and 4 characters for the year.


So... if my local date looks like 02-15-13

DatePart> will give me 2, 15 and 2013. I can then pad zeros on to month and day if I need them and truncate the year if I only want a two character year.

Will DatePart> ALWAYS give me month and day with no leading zeros and a four character year?

[Marcus Tettmar]

Should do yes. Should be consistent. But you could always left pad with zeros and extract right two digits and that way you know you'll ALWAYS have 2 digits.