I think there's a bug in the parsing of ISO 8601 date strings. I tried the following in my Chrome console:

var t = Tempus()
t.toISO8601String()
"2012-06-28T00:24:49.883+0100"
var u = Tempus("2012-06-28T00:24:49.883+0100")
u.toISO8601String()
"2012-06-27T00:24:49.883+0100"

We've lost a day...

Once I get past the jshint errors, when I run npm test, I get the following error. This stack trace is not very informative, but I'll dig a little and see if I can find out more.

Running "qunit:index" (qunit) task
Verifying property qunit.index exists in config...OK

Testing index.html

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: spawn ENOENT
    at errnoException (child_process.js:1001:11)
    at Process.ChildProcess._handle.onexit (child_process.js:792:34)
npm ERR! Test failed.  See above for more details.
npm ERR! not ok code 0

UTCDay and UTCISODay methods need to be created, so that UTC operations on these two methods can be done.

Hi!

Want to improve Tempus? On a 24pullrequests binge? Are you thinking of making a PR? Well, I'm going to ask you to hold off just for now.

Tempus has had a serious lack of love over the last year. Mostly because I was kind of unhappy with the project and its direction. However, I've been inspired to work on a brand new version which will be a ground-up rewrite, featuring a new, much nicer API, and some awesome new features. As such Tempus 1.x will be left here in the meantime to grow some more cobwebs.

The Plan

Like I've said to @johnmarkos over in #30, a 2.x branch will appear here in the next couple of weeks, which will feature a fairly feature complete Tempus 2.0 implementation. At this point I'll need testers, tweakers and documentation polishers to help me finish it off for release. If you've read this far, and are still interested, then I would be totally chuffed to have you on board!

If you're interested, throw a +1 or subscribe to this issue, and I'll update you all when the 2.x branch has been pushed, and I'll fill up the issue tracker with some great new tickets to tear through. I'll make sure to do this before December is over - so if you are doing 24pullrequests, then you'll have lots of exciting stuff to work on toward the end of the month here 😉. (update: sorry, busy christmas period meant I didn't get round to pushing working at all on tempus

http://tempus-js.com/docs/developer-preface is referenced in the README.md but the link is broken.

Hi keithamus,
What do you think to make timeString("NN:NN") equivalent to timeString("NN:NN:00")?

By extending the concept, you may set to zero any digit that is not specified, e.g. timeString("N") would become equivalent to timeString("N0:00:00").

Thanks!

G.

Languages like Python and .NET have high resolution dates, which record up to microseconds (6 digit fraction of a second). Their iso string functions send dates with microseconds in them.

Tempus currently only parses dates strictly with milliseconds. This needs to change to support these languages.

Possible Solutions:

• Turn the ISO8601 constant to an array of possible formats, and ensure the reverse format parser can deal with deep arrays
• Code up a dedicated ISO8601 parser which deals with the dynamics of an ISO8601 date
• Code up a dedicated ISO8601 parser which normalises it down to our preferred format.

------- (Add comments above this line) -------
"http://tempus-js.com/docs/developing-with-tdd" is a 404 link, coming from "http://tempus-js.com/docs/".
Visited on: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36"

Would love to use this in my project, but need to know how to do so using AMD, does that doc exists? Thanks

------- (Add comments above this line) -------
"http://tempus-js.com/docs/browser-using-with-amd" is a 404 link, coming from "http://tempus-js.com/docs/".
Visited on: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11"

Could we add functionality to set day with a string, such as:

new Tempus().setDayName('monday');

All tests are written to the UK locale, which means when they are loaded into a different locale, the test break. This is not necessarily code breaking (although it could be), but more that the tests are written too fixed.

Proposed Solutions:

1. Rewrite all failing tests to be more timezone independent.
2. Have & load in separate test suites for each timezone locale, which has the advantage of introducing locale specific tests, but the disadvantage of being a massive pain in the arse to maintain.

------- (Add comments above this line) -------
"http://tempus-js.com/docs/detailed-overview" is a 404 link, coming from "http://tempus-js.com/".
Visited on: "Mozilla/5.0 (Windows NT 6.2; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0"

Lots of failing tests (currently 63) on the Travis-CI build: http://travis-ci.org/#!/keithamus/Tempus

Some of these are likely other bugs (especially #3).

Before 0.2 can be released, we need test-pass parity with Travis-CI, which will ideally be all passing tests

Tempus().toString('%D') => '05/04/12'
Tempus().toString('%a %b %d %T %Y') => 'Fri May 04 17:58:48 2012'

Don't know if this is correct, but it doesn't match the behaviour specified for '%D' at http://tempus-js.com/api/toString/

I'll fix and file a pull request at some time when I'm not late for the pub.

The Blog is a great way to talk about public uses of Tempus, or ways people have used it to accomplish cool stuff. Anyone is free to write an article, just send a pull request over.

The best suited articles for the blog are:

• Tutorials on a cool use case for Tempus, for example, generating calendars, making new date parsers
• Discussing how Tempus has been used in production environments
• Detailing the progress of Tempus, especially highlighting new methods and what to use them for.

Some dos and donts:

• Do write the article in markdown
• Do include author information, including author_name, author_gravatar_id, author_website, author_bio in the yml front matter
• Do keep the author_bio to less than 144 characters. (Why? Because if you can keep it short on twitter, you can keep it short here).
• Do keep the articles brief and to the point
• Do feel free to add humour, or personality.
• Don't attempt to send pull requests of articles which overtly advertise something, or endorse a company
• Don't spread articles into multi-part posts
• Don't mention illegal or morally questionable activities inside articles, including pornography, keep it SFW
• Don't swear
• Don't intimidate or belittle the audience

This fails with the wrong Year:

Tempus.addTimeFormat({Twitter: "%a %b %d %H:%M:%S GMT%z %Y"});
var s = new Tempus("Mon Apr 10 14:45:00 GMT+0000 2012").toString("%Y-%m-%d %H:%M:%S %Z");

Expected:

2012-04-10 14:45:00 +00:00

Actual

2013-04-10 14:45:00 +00:00

Ops. :/
------- (Add comments above this line) -------
"http://tempus-js.com/docs/date-formatting" is a 404 link, coming from "http://tempus-js.com/docs/".
Visited on: "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1541.2 Safari/537.36"

It would be great to get some set-up guides, and general how-to guides in the documentation.

So far no documentation exists, only a very bare outline for some docs. It would be good to flesh these out with ideas like:

• How to get it running in Node-JS (npm install, etc)
• How to get it running in the Browser (git submodule?)
• The different types of methods (getters, setters, iterators, assertions) and what they do...
• How to use setters/getters
• How to chain
• How to use assertion methods (is*)
• How to use iterator functions
• Reverse formatting
• Formatting dates
• Adding your own date parsers
• How to contribute (including docs on TDD)

The "Docs" pages should be general purpose documentation, on issues such as how to get it working, the paradigms & behaviours around Tempus, and guides that require more specific detail than the API docs can offer (for example a section on date formatters or reverse formatters). Leave specific signature patterns for the API docs, and specific use cases for the blog.

The page http://tempus-js.com/api/ says:
"year: Set or get the full, 4 digit year"

However the doc at http://tempus-js.com/api/year says:
"Get the 2 digit year, i.e 12"

Same thing for getYear and setYear

There are 20 failing tests on the current build, that are related to missing coverage. These methods are automatically generated (curried) in the code, and so tests were missed on these.

These are the following:

Coverage for UTCOrdinalHours not present!
Coverage for getUTCTime not present!
Coverage for setUTCTime not present!
Coverage for addUTCTime not present!
Coverage for subUTCTime not present!
Coverage for UTCTime not present!
Coverage for getUTCOrdinalHours not present!
Coverage for setUTCOrdinalHours not present!
Coverage for addUTCOrdinalHours not present!
Coverage for subUTCOrdinalHours not present!
Coverage for getUTCISODay not present!
Coverage for setUTCISODay not present!
Coverage for addUTCISODay not present!
Coverage for subUTCISODay not present!
Coverage for UTCISODay not present!
Coverage for getUTCDay not present!
Coverage for setUTCDay not present!
Coverage for addUTCDay not present!
Coverage for subUTCDay not present!
Coverage for UTCDay not present!

The developer preface link is broken in the readme.

------- (Add comments above this line) -------
"http://tempus-js.com/docs/developer-preface" is a 404 link, coming from "https://github.com/keithamus/Tempus" (README.md).
Visited on: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17"

Timezone support does not work very well, as it spills over hours, days, etc.

For example, if you are at the end of the day (say, the 23rd hour) in UTC, and you set the timezone to +0400, then getHours() will return 26. Similarly getDate() will return the wrong date (as the timezone is now the next day).

This bubbles up to Days, Weeks, Months, Years. Each one can hit an edge where the timezone should rollover the unit (e.g days) but doesn't.

Proposed Solutions:

1. Add a method which is called inside each of the unit getters to check for spill-over, and adjust accordingly.
2. Maintain 2 private Date() objects, one is the UTC representation of date, the other is the timezone representation of the date. Use UTC* methods for all internal Date() calls.
3. Set the internal _date object only using UTC methods (ignoring _date's internal tz data) and including Tempus tz data, and for Tempus' UTC methods 0 out the timezone, get the date info and put the tz back.

My money is on style 3

------- (Add comments above this line) -------
"http://tempus-js.com/docs/date-formatting" is a 404 link, coming from "http://tempus-js.com/docs/".
Visited on: "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36"

var d = new Tempus('2012-04-29 23:06:00');

TypeError: Cannot call method 'getTimezoneOffset' of undefined

Stack Trace:

TypeError: Cannot call method 'getTimezoneOffset' of undefined
    at Tempus.setTimezoneToLocale (http://192.168.1.94/lib/tempus.js:538:45)
    at Tempus.set (http://192.168.1.94/lib/tempus.js:263:18)
    at new Tempus (http://192.168.1.94/lib/tempus.js:34:18)
    at unknown source
    at Object._evaluateOn (unknown source)
    at Object._evaluateAndWrap (unknown source)
    at Object.evaluate (unknown source)

Browser: Google Chrome V 18.0.1025.163
O/S: OSX 10.7.2

http://tempus-js.com/api/now/

This page first says Tempus.now() returns seconds since epoch but then subsequently says it's the same as Date.now() which returns milliseconds. On testing it is indeed milliseconds not seconds.

On line 857, inside the first default parser:

strftimeRegExp.test(b)

Where strftimeRegExp is /\%([OE])?([a-z%])/gi

using test() on a regexp that has the g modifier gives different results each time you run it. See here. This causes problems if Tempus is called repeatedly with the same string format - it fails every fourth attempt.

You can remove the g or reset lastIndex before each test.

Good framework. I saw your talk at LNUG and when I came to start using dates in js I looked it up. Would be good to see a complete API reference though.

Cheers

The API docs should have 100% coverage on all methods inside Tempus.

This is currently not the case. This is a high-priority issue, as methods that aren't documented are as-good-as a waste of code.

------- (Add comments above this line) -------
"http://tempus-js.com/docs/node-getting-started" is a 404 link, coming from "http://tempus-js.com/docs/".
Visited on: "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0"