2

I want to make this 1332251639632 to this 1332251639

I try this code, but since is not a string it dosent work

var date = new Date();
var t = date.getTime();
var p = t.substring(10);

alert(p);

I want to cut it since in php time() return 10 digit number

Ben
  • 1,906
  • 10
  • 31
  • 47

6 Answers6

2

Like this?

var p = parseInt(t/1000);
Ilia Frenkel
  • 1,969
  • 13
  • 19
  • Does using `parsInt` on a `Number` have any (dis)advantages over just using `Math.floor(t/1000)`? – Chris Wesseling Apr 05 '12 at 12:22
  • @Chris Wesseling numbers are primitive types. **Number** is a wrapper - it will create a number object. – Bakudan Apr 05 '12 at 16:02
  • @Bakudan OK, didn't know that. Still the v8 engine seems to take a tiny performance hit when doing `parseInt` compared to using `Math.floor`. See my [answer](http://stackoverflow.com/a/10028887/383793). – Chris Wesseling Apr 05 '12 at 16:11
2

I have the opinion that a better approach is:

var dateObject = new Date(),
    time = dateObject.getTime();
Math.floor ( time / 1000 );

Now the reasons are:

  1. parseInt()ECMA Specs expects a string to be converted by a certain radix. Behind the scene the interpreter is working with strings and at the end returns integer number. Example MDN how the function is intended to work. As Chris Wesseling points the it is slower because of the additional work with the string and radix. ES5 which will be implemented in the future versions of the browsers, will impose the usage of radix, here is why:

    parseInt( "011" ); //returns 9, 0 starting string is indicating octal number

    parseInt( "011", 10 ); //returns 11, as expected

  2. getTime()MDN will return a number, milliseconds since 1 January 1970 00:00:00 UTC, there is no convertion from string to number. This means "semantically" is better to use rounding function.

  3. floor(x)ECMA Specs is intended to work with numbers. Returns the greatest Number value that is not greater than x. Usage MDN
  4. ceil(x)ECMA Specs is almost the same - returns the smallest Number value that is not less than x. Usage MDN

A little off-topic Even the Linux y2k(38) problem won't make any difference because the number is 64-bit, and the integer in Javascript is presented in 53-bitsECMA Specs SO question.

Community
  • 1
  • 1
Bakudan
  • 19,134
  • 9
  • 53
  • 73
1

You could do it with rounding as suggested Ilia's solution, or with substring like this:

var date = new Date();
var t = date.getTime().toString();
var p = t.substring(0, 10);

alert(p);
Dan Prince
  • 29,491
  • 13
  • 89
  • 120
  • I don't think there will be a rounding. In JavaScript the integer is big enough. And the whole snippet can be shortened: `alert ( +new Date() );​` – Bakudan Apr 25 '12 at 08:11
0

Try:

var t = "" + date.getTime();
var p = t.substring(0,10);
Travis J
  • 81,153
  • 41
  • 202
  • 273
  • 1
    It would be cleaner to use toString() rather than implicit type conversion with the empty quotes. – Dan Prince Apr 05 '12 at 00:55
  • @Travis J you should really read [JavaScript ubstring](https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String/substring) - with one paramater means from this position, not length. – Bakudan Apr 05 '12 at 00:58
  • @Bakudan - Have read that, but was just using the OP's example. It should correctly read `t.substring(0,10);` – Travis J Apr 05 '12 at 01:02
  • @DanPrince - cleaner, but slower. http://jsperf.com/tostring-implicit-vs-explicit – Travis J Apr 05 '12 at 01:06
  • 1
    @Travis J And the time it could save you when you hit a bug could largely outweigh the tiny time difference between the two ;) – Dan Prince Apr 05 '12 at 01:08
  • @Travis J we are not interested in the bugs in the OP's question. We are interested in your answer. And obviously it was wrong, BEFORE the edit. – Bakudan Apr 05 '12 at 01:12
  • @TravisJ The bug isn't necessarily going to occur within the conversion, but perhaps later on when you are expecting an number, but instead you get a string, because you missed the line with the messy ""+ appended to the front. Doesn't matter whether it is a small example, write code that can be re-used for other modules and designs. – Dan Prince Apr 05 '12 at 01:23
  • +1. Yay for implicit type conversion. No doubt those who like `String(…)` also abhor seeing `var a = new Array()` instead of an empty array literal. Go figure. – RobG Apr 05 '12 at 02:16
  • @DanPrince - `"" + ` conversion is perfectly re-usable. It is your variable names which should reflect the type of the variable, not what would be assumed. Stop making assumptions and your code will get a lot better. – Travis J Apr 05 '12 at 03:32
0

How about this?

var date = new Date();
var t = date.getTime();
var p = parseInt(t.toString().match(/\d{10}/));

alert(p);

It converts the number into a string, matches the first 10 digits, then reconverts the result into number.

undefinederror
  • 821
  • 1
  • 8
  • 16
0

Curious whether there was any difference between

var p = parseInt(t/1000);

and

var p = Math.floor(t/1000);

I did this:

 start = new Date().getTime(); for ( var i=0; i<1000000; i++) parseInt(start/1000); new Date().getTime() - start;

And

start = new Date().getTime(); for ( var i=0; i<1000000; i++) Math.floor(start/1000); new Date().getTime() - start;

In Chromium parseInt would take about 7.2 seconds against Math.floor 6.6 on my netbook.

Firefox complained about the script taking to long. It could only do 200000 operations in about the same time.

So I guess this is very implementation dependent.

Chris Wesseling
  • 6,226
  • 2
  • 36
  • 72
  • See [my answer](http://stackoverflow.com/a/10033092/179669) - the parseInt function is working with string, and there are a lot more work behind the scene. The implementation is shown in the ECMA specs, and ther is a big difference. – Bakudan Apr 05 '12 at 17:25