function lpad(val, digits) {
    return String(val + Math.pow(10, digits)).substr(1);
}
dateTime2ms - turn a date object or string s into milliseconds
(relative to 1970-01-01, per javascript standard)
optional calendar (string) to use a non-gregorian calendar

Returns BADNUM if it doesn't find a date

strings should have the form:

   -?YYYY-mm-dd<sep>HH:MM:SS.sss<tzInfo>?

<sep>: space (our normal standard) or T or t (ISO-8601)
<tzInfo>: Z, z, [+\-]HH:?MM or [+\-]HH and we THROW IT AWAY
this format comes from https://tools.ietf.org/html/rfc3339#section-5.6
and 4.2.5.1 Difference between local time and UTC of day (ISO-8601)
but we allow it even with a space as the separator

May truncate after any full field, and sss can be any length
even >3 digits, though javascript dates truncate to milliseconds,
we keep as much as javascript numeric precision can hold, but we only
report back up to 100 microsecond precision, because most dates support
this precision (close to 1970 support more, very far away support less)

Expanded to support negative years to -9999 but you must always
give 4 digits, except for 2-digit positive years which we assume are
near the present time.
Note that we follow ISO 8601:2004: there *is* a year 0, which
is 1BC/BCE, and -1===2BC etc.

World calendars: not all of these *have* agreed extensions to this full range,
if you have another calendar system but want a date range outside its validity,
you can use a gregorian date string prefixed with 'G' or 'g'.

Where to cut off 2-digit years between 1900s and 2000s?
from https://docs.microsoft.com/en-us/office/troubleshoot/excel/two-digit-year-numbers#the-2029-rule:
  1930-2029 (the most retro of all...)
but in my mac chrome from eg. d=new Date(Date.parse('8/19/50')):
  1950-2049
by Java, from http://stackoverflow.com/questions/2024273/:
  now-80 - now+19
or FileMaker Pro, from
     https://fmhelp.filemaker.com/help/18/fmp/en/index.html#page/FMP_Help/dates-with-two-digit-years.html:
  now-70 - now+29
but python strptime etc, via
     http://docs.python.org/py3k/library/time.html:
  1969-2068 (super forward-looking, but static, not sliding!)

lets go with now-70 to now+29, and if anyone runs into this problem
they can learn the hard way not to use 2-digit years, as no choice we
make now will cover all possibilities. mostly this will all be taken
care of in initial parsing, should only be an issue for hand-entered data
currently (2016) this range is:
  1946-2045