3

Frequently, when writing time-related code, I write the following:

const SECONDS = 1000;
const MINUTES = 60 * SECONDS;
const HOURS = 60 * MINUTES;
const DAYS = 24 * HOURS;

(of course these are variables not constants, but they will never change, and I could make them un-changeable properties etc if I wanted to)

However I suspect these values already exist inside V8 / JavaScriptCore / Chakra and other JS engines.

  • Is there a standard way to access these values in JavaScript, perhaps somewhere off the Date constructor?
  • Is there a non-standard way to access these values, say something V8 specific?
mikemaccana
  • 110,530
  • 99
  • 389
  • 494
  • 1
    You might want to see if [moment.js](http://momentjs.com/) can do what you need before rolling your own – Plato Jun 06 '13 at 18:26
  • in javascript var is used for local variables, you can use const SECONDS =1000; – argentum47 Jun 06 '13 at 18:28
  • @plato I don't want to roll my own or use a library. My question is about whether these values that exist in the JS engine are exposed, so I can simply access them without duplicating logic. – mikemaccana Jun 06 '13 at 18:31
  • @blackbee const isn't a standard. – mikemaccana Jun 06 '13 at 18:31
  • i think its supported by all modern browser except for ie and can be used independent to Rihno or Node.js – argentum47 Jun 06 '13 at 18:33
  • @blackbee False. See this [link](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const#Browser_compatibility). IE does not support it. Safari and Opera do not treat it as read only... – War10ck Jun 06 '13 at 18:33
  • http://stackoverflow.com/questions/130396/are-there-constants-in-javascript – argentum47 Jun 06 '13 at 18:35
  • http://stackoverflow.com/questions/664829/javascript-final-immutable-global-variables – argentum47 Jun 06 '13 at 18:37
  • **Const** is not part of ECMAScript, not supported by all browsers, not reliable and therefore not a good solution. – War10ck Jun 06 '13 at 18:44
  • @War10ck: see `node.js` tag. The V8 engine **does** support `const`. – Sébastien Renauld Jun 06 '13 at 19:18
  • 1
    @SébastienRenauld I never said it didn't. It's not supported in **all** browsers therefore it is not a _standard_ the OP can access reliably. It works via selective engines. However, if the OP wants code that runs in all browsers and not just a handful, it is not a reliable method for them to use. The question was tagged node.js but I did not see any node.js specific content. I was commenting on the const keyword as a whole not of node.js. My apologies for any confusion. – War10ck Jun 06 '13 at 19:30
  • That's a handsome mustache. – Mulan Jun 06 '13 at 19:34

3 Answers3

3

However I suspect these values already exist inside V8 / JavaScriptCore / Chakra and other JS engines.

They are not exposed in any standard way. Language designers tend to expose a few things like Math.PI and Math.E which have to be approximated carefully to avoid errors in numerical code, but adding a bunch of universal constants for integers just bloats APIs and slows down interpreter startup.

Mike Samuel
  • 118,113
  • 30
  • 216
  • 245
  • Thanks @Mike that was exactly the answer I was looking for (even if it wasn't the answer I wanted). You get it: much like Math.PI, I'd hoped for other common constants to be available somewhere. It looks like they aren't. – mikemaccana Jun 06 '13 at 20:47
  • Not quite like "other constants". Pi and e both require a rather complex evaluation to approximate - your constants are integers. By storing Math.PI, you're gaining in efficiency. By storing 1000, you're losing. – Sébastien Renauld Jun 06 '13 at 20:56
  • @SébastienRenauld, the closest IEEE-754 64b values to *e* and *π* are [known](http://grouper.ieee.org/groups/754/email/msg04205.html), and could be specified (`var PI = ...;`) by every piece of code that needs them. There's no need to write code to compute either even if you don't want to hard code them to the embedding language's precision : `Math.exp(1)` and `Math.acos(-1)` work just fine. – Mike Samuel Jun 06 '13 at 21:45
  • @SébastienRenauld But it can can clearly be proven that the JS engine already knows how many days are in a week. There would be little overhead in exposing it (and it would, obviously, save a few common lines of code). – mikemaccana Jun 06 '13 at 21:51
  • 1
    @nailer, If you're dealing with a historical calendar (non-proleptic), not all weeks have the same number of days. [Gregorian Calendar history and facts](http://www.naturcalendar.com/Tutorial/GregorianCalendar.htm) says "Italy: 4 Oct 1582 was followed by 15 Oct 1582" so if the JS engine's non-UTC (which is usually proleptic) timestamp<->date calculation system takes into account the Julian/Gregorian switchover, then it does not assume the number of days in a week is always 7 since in many timezones 2-3 weeks have fewer than 7 days. – Mike Samuel Jun 06 '13 at 21:58
  • @Mike an excellent point - the assumption that there are 24 hours in every day also won't always be true. – mikemaccana Jun 06 '13 at 22:02
  • @MikeSamuel: Because you think that `acos` is a literally computable function? Think again. http://mathworld.wolfram.com/InverseCosine.html – Sébastien Renauld Jun 06 '13 at 22:51
  • @SébastienRenauld, I think no such thing, but I do think that EcmaScript specifies a `Math.acos` function. – Mike Samuel Jun 07 '13 at 01:46
2

If you would like to do this, you are better off (due to Node's require() peculiarities) defining a new module and write it as follows:

 module.exports = {
     seconds: 1000,
     minutes: 60000,
     hours: 3600000,
     days: 86400000
 }

This will allow to simply use require("yourmodulename").seconds and similar whenever required. The object will only be imported once.

Sébastien Renauld
  • 19,203
  • 2
  • 46
  • 66
  • A good point - a module would handle doing it myself fine, however my question is whether or not there's a way to avoid doing it myself completely. – mikemaccana Jun 06 '13 at 18:29
  • @nailer: short answer is "nope". Long answer is: no `Date` object function covers that. – Sébastien Renauld Jun 06 '13 at 18:31
  • This is the correct approach. If you want constants or functions that would serve as an extension to an existing class (`Date`), you should contain them in a separate module. This way you can reuse it in any projects that would need this code. For what it's worth, these numbers are pretty pointless; at least outside of this module; you wouldn't need the publicly exposed at all. My hunch is that you're using these values to perform additional calculations somewhere else in your code. That code should be encapsulated in reusable functions and put in this module as well. – Mulan Jun 06 '13 at 19:37
  • Could the downvoter have the guts to point out *why* they downvoted everyone on this question thread? – Sébastien Renauld Jun 06 '13 at 20:44
  • @SébastienRenauld The answer above does not answer the questions, which are: "* Is there a standard way to access these values in JavaScript, perhaps somewhere off the Date constructor? * Is there a non-standard way to access these values, say something V8 specific?" – mikemaccana Jun 06 '13 at 21:53
  • @nailer: The answer hints at it and provides a fallback. One of the comments provides a definite answer. – Sébastien Renauld Jun 06 '13 at 22:50
0

I was looking to do the same thing and thought Date.prototype might work but it didn't. Found something like this in other SO answers:

Object.defineProperty(Date, "sec", { value: 1000 });
Object.defineProperty(Date, "min", { value: Date.sec*60 });
Object.defineProperty(Date, "hour", { value: Date.min*60 });
Object.defineProperty(Date, "day", { value: Date.hour*24 });
SuperCodeBrah
  • 2,874
  • 2
  • 19
  • 33