Javascript and working with dates

[Thomas 'PointedEars' Lahn]

Date.prototype.fmt = function(format) {
var d = this;
return format.replace(/%([CdFfHMmnRSTYy%])/g,
function(m, p1) {
[...]
});
};

Very good modifications. But won't it be better if we use a cached
copy of the RegExp native object instead of creating a new one on each
invocation?

It would, if what you describe were the case. With a RegExp literal
no new object is created, but an already existing object is being
referred to. So there is no need for optimization through "caching":

,-[ECMAScript Language Specification, Edition 3 Final]
|
| 7 Lexical Conventions
|
| The source text of an ECMAScript program is first converted into
| a sequence of input elements, which are either tokens, line
terminators,
| comments, or white space. The source text is scanned from left to
right,
| repeatedly taking the longest possible sequence of characters as
| the next input element.
|
| [...]
|
| 7.8.5 Regular Expression Literals
|
| A regular expression literal is an input element that is converted
to
| a RegExp object (section 15.10) when it is scanned. The object is
| created before evaluation of the containing program or function
begins.
| Evaluation of the literal produces a reference to that object; it
does
| not create a new object.
|
| [...]
| Semantics
|
| A regular expression literal stands for a value of the Object type.
| This value is determined in two steps: first, the characters
comprising
| the regular expression's RegularExpressionBody and
RegularExpressionFlags
| production expansions are collected uninterpreted into two strings
Pattern
| and Flags, respectively. Then the new RegExp constructor is called
with
| two arguments Pattern and Flags and the result becomes the value of
the
| RegularExpressionLiteral. If the call to new RegExp generates an
error,
| an implementation may, at its discretion, either report the error
| immediately while scanning the program, or it may defer the error
until
| the regular expression literal is evaluated in the course of program
| execution.


PointedEars

 

[Thomas 'PointedEars' Lahn]

[supersedes GG-miswrapped version]

Date.prototype.fmt = function(format) {
var d = this;
return format.replace(/%([CdFfHMmnRSTYy%])/g,
function(m, p1) {
[...]
});
};

Very good modifications.
Thanks.

But won't it be better if we use a cached copy of the RegExp
native object instead of creating a new one on each invocation?

It would, if what you describe were the case. With a RegExp literal
no new object is created, but an already existing object is being
referred to. So there is no need for optimization through "caching":

,-[ECMAScript Language Specification, Edition 3 Final]
|
| 7 Lexical Conventions
|
| The source text of an ECMAScript program is first converted into
| a sequence of input elements, which are either tokens, line
| terminators, comments, or white space. The source text is scanned
| from left to right, repeatedly taking the longest possible sequence
| of characters as the next input element.
|
| [...]
|
| 7.8.5 Regular Expression Literals
|
| A regular expression literal is an input element that is converted
| to a RegExp object (section 15.10) when it is scanned. The object
| is created before evaluation of the containing program or function
| begins. Evaluation of the literal produces a reference to that
| object; it does not create a new object.
|
| [...]
| Semantics
|
| A regular expression literal stands for a value of the Object type.
| This value is determined in two steps: first, the characters
| comprising the regular expression's RegularExpressionBody and
| RegularExpressionFlags production expansions are collected
| uninterpreted into two strings Pattern and Flags, respectively.
| Then the new RegExp constructor is called with two arguments
| Pattern and Flags and the result becomes the value of the
| RegularExpressionLiteral. If the call to new RegExp generates an
| error, an implementation may, at its discretion, either report
| the error immediately while scanning the program, or it may defer
| the error until the regular expression literal is evaluated in
| the course of program execution.


PointedEars

 

[sasuke]

[supersedes GG-miswrapped version]

Date.prototype.fmt = function(format) {
  var d = this;
  return format.replace(/%([CdFfHMmnRSTYy%])/g,
    function(m, p1) {
      [...]
    });
};

Very good modifications.

Thanks.

You are most welcome.

But won't it be better if we use a cached copy of the RegExp
native object instead of creating a new one on each invocation?

It would, if what you describe were the case.  With a RegExp literal
no new object is created, but an already existing object is being
referred to.  So there is no need for optimization through "caching":

,-[ECMAScript Language Specification, Edition 3 Final]

[enlightening piece of text]

My bad; I did search the specification document for words like
'cache', 'cached' etc. in terms of Regular expressions but to no
avail. I should have known better than trying to use implementation
dependent terms as search keywords. I have always used global RegExp
literals for two reasons: to prevent new RegExp object creation and
for the sake of maintainability; I guess I need to strike out the
former.

It would be interesting to note the behavior of the implementation in
memory limited environment when faced with a extremely large number of
RegExp literals; would it then go in favor of implementing LFU/LRU
policy or prefer to throw an OOM (out of memory) error. Just a thought
though.

/sasuke

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>
, Sat, 20 Sep 2008 00:34:29, SAM <[email protected]
alid> posted:

Example with a trap over February:
==================================
var y = 2005, m = 03, d = 30; // 30/03/2005 (in dd/mm/yyyy)
var D = new Date(y, +m-1, d); // the orginal JS date
D.setDate(D.getDate()-30); // 30 days less
// that is done
alert( d+'/'+m+'/'+y+
' = original date\n'+
D.getDate()+'/'+(+D.getMonth()+1)+'/'+D.getFullYear()+
' = date - 30 days'):

As new Date() is not used, then it is not a "real-time" question. For
such, it is more efficient, and in some cases may avoid obscure error,
to work entirely in UTC.

var D = new Date(Date.UTC(y, m-1, d - 30))
// then output D using UTC methods.

If there are still browsers that don't like non-positive day-of-month,
then move the 30 to between the parentheses, multiplying it by 864e5.

 

[Dr J R Stockton]

I can't recall any language that makes dealing with dates easy.

Icelandic Javascript. UTC all year round, unless they join the EU.
VBScript, for those few who are Americans or similar AND have discovered
DateSerial(y,m,d).

Opera is 9.60.