Rules for the date string used by DOpus.Create.Date

What are the rules for the date string sDate used in DOpus.Create.Date (sDate)?

  • sDate = "2007/08/09" and "2007-08-09" and "2007 08 09" and "2007 Aug 9" all yield 9th August 2007.

  • sDate = "07/08/09" and "07-08-09" and "07 08 09" and "7 Aug 09" all yield 7th August 2009.
    — But in a different locale, I expect that they would all yield 8th July 2009.

SPECIFICALLY: Are there codes that can be placed within the string to specify the meaning of each item in the date and time?

You can create a date object and then modify individual elements. For example:

var d = DOpus.create.date(); DOpus.output(d); d.day=7; DOpus.output(d);
This might generate..

9/11/2016 10:23:57
7/11/2016 10:23:57

Regards, AB

Thanks, aussieboykie. I know that I can do that, but it throws errors when the data is faulty. In particular, it does not interpret a two-digit year. For example:

  • d.year = 2007 does indeed make the year 2007.
  • d.year = 07 throws an error rather than interpreting the date using the locale.

This problem arises when you don't have control over the data coming in to your script, so that it may contain two-digit years — if all the years were four-digit years, the problem would not arise because the string sDate would handle it.

Of course I can workaround this by writing into the script your own locale conditions specifying how to interpret a two-digit year before I form the date string sDate. But:

  • It would be cleaner to know the rules, and
  • It would be cleaner still to be able to insert codes into the date string.
    I haven't been able to find answers to these two things from the DOpus Help, but I routinely miss things.

Opus actually expects a VT_DATE variant in this case; if you supply a string it'll be converted behind the scenes but it's not Opus doing the conversion, it's COM/ActiveX. You might be able to use the CDate() function to control the process better, I'm not sure.

Thanks Jon. I had a look at CDate, but it also uses the locale. Instead, an easy workaround is:

  • Build up any two-digit year to a four-digit year that differs from the current year by at most 50 years.
  • Arrange the date string sDate into the bigendian form yyyy-month-day.
  • DOpus.Create.Date (sDate) now reads the date in unambiguously because the first element can only be the year.
    So problem solved.

I read a bit about CDate and about the complexities of the user's locale! I know that parsing the date string is tricky, but I had no idea that it is such a problem.

Funny thing: ddDate = DOpus.Create.Date ("2010-Aug-21") works, but trying to set the month afterwards by ddDate.month = "Aug", after already having created the date object, throws an error — you have to use a number. It's a very confused and unsatisfactory situation.