Thread-safety
The implementation is not thread-safe.
checkstring
calls functions that mutate the internal state of the instance (naturalDate
and unixTime
),
so if this function gets called from concurrent threads,
you may get incorrect results.
You can easily make it thread-safe by eliminating the naturalDate
and unixTime
fields.
You don't need them.
These can be local variables in checkstring
,
and passed as parameters to getResults
.
In fact, the best would be to replace getResults
with dedicated functions that return {unix: ?, natural: ?}
with the appropriate value filled.
(See further below.)
Design
Also, I would spell out nat
as natural
in unixToNat
and natToUnix
.
Thread-safety
It's true that thread-safety is not a practical concern in JavaScript, as user code is typically executed on a single thread in browsers and in node.js too. However, I think it's still a good idea to write thread-safe code when it's easily possible, in order to avoid picking up bad habits that may bite you later in other languages.
The implementation is not thread-safe.
checkstring
calls functions that mutate the internal state of the instance (naturalDate
and unixTime
),
so if this function gets called from concurrent threads,
you may get incorrect results.
You can easily make it thread-safe by eliminating the naturalDate
and unixTime
fields.
You don't need them.
These can be local variables in checkstring
,
and passed as parameters to getResults
.
In fact, the best would be to replace getResults
with dedicated functions that return {unix: ?, natural: ?}
with the appropriate value filled,
as I did in the examples above.