js-joda/js-joda

:clock2: Immutable date and time library for javascript

js-joda's Issues

Test for mobile browsers

Hi all,

Do you have information on, or tests for, the performance of JS-Joda on mobile devices? First of all, because there are a lot of mobile visitors to web pages and secondly, it would be great to use this package in Cordova, where you build apps using html and javascript.
I would love to know whether js-joda, or what parts of js-joda, work on which mobile browsers (preferrably android 4.0 and up), and maybe help make it compatible.

Cheers!

Change the private constructors to static private factory functions (`_ofXXX`)

As proposed in #131 (comment)

Get rid of all(?) private constructors in js-joda and move them to private factory functions (_of)
So they do not appear in the esdoc and cannot cause confusion on how to create date objects

An in-range update of eslint-plugin-standard is breaking the build 🚨

Version 2.2.0 of eslint-plugin-standard just got published.

Branch	Build failing 🚨
Dependency	eslint-plugin-standard
Current Version	2.1.1
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As eslint-plugin-standard is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

---

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 3 commits .

• db69e45 2.2.0
• 9256b1d no-callback-literal: remove next() from default list
• a9c173f badges

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

Question: Ultra verbose rendering of ZoneId when using chai.js

When using chai and chai displays a diff for assertion failure the ZoneId is rendered along with all the timezome rules (using js-joda-timezone of course). eg

  {
    "device_uuid": "device-1"
    "end": {
      "_dateTime": {
        "_date": {
          "_day": 13
          "_month": 3
          "_year": 2017
        }
        "_time": {
          "_hour": 10
          "_minute": 0
          "_nano": 0
          "_second": 0
        }
      }
      "_offset": {
        "_id": "+01:00"
        "_rules": {
          "_offset": [Circular]
        }
        "_totalSeconds": 3600
      }
      "_zone": {
        "_id": "Europe/Berlin"
        "_rules": {
          "_ldtUntils": {
            "_ldtUntils": [
              [undefined]
              [undefined]
              [undefined]
              [undefined]
              [undefined]
              [undefined]
              ...
              ...

Is this because ZoneRegion does not implement a nicer toString()

some classes not listed in dist

Hi,

Navigating under the JSJoda object I get when importing https://rawgit.com/js-joda/js-joda/master/dist/js-joda.js , I see it is missing some things from the api, for example Temporal or TemporalAccessor. Would it be possible to have a way to access these things other than via this sort of thing?

JSJoda.DayOfWeek.FRIDAY.__proto__

Thanks

Documentation is just copied from the Java world

The documentation of js-joda is just copied from the https://github.com/ThreeTen/threetenbp java repo. The Threeten docu contains tons of very interesting and helpful information's not only about the lib itself but about date and time issues in general. But it contains references to java specific issue and java specific types, such as long/ int issues or thread-safe issues. And it contains javadoc tags, that are invalid for esdoc.

The only things we did so far, was to adapt the esdoc javascript parameters, so the esdoc docu and the IDE support for parameter looks good.

But the rest of the documentation needs to be reworked. The java issues must be removed/ adapted and javascript specific issues like floating-point, MAX/ MIN_SAFE_INTEGER must be added.

Add method withResolverStyle to DateTimeFormatter

Please add this method present in Java's Joda.

I can't construct a formatter (parser) in strict mode using TypeScript.

Add different standard date-time formatters/parsers

e.g.:

const AMERICAN_DATE_FORMATTER = DateTimeFormatter.ofPattern('MM/dd/yyyy');

LocalDateTime.ofInstant() throws a TypeError

Hello,

when I invoke

LocalDateTime.ofInstant(1459546270798)

I get the following stacktrace:

TypeError: localDateTime.toEpochSecond is not a function
at SystemDefaultZoneRules.offsetOfLocalDateTime (.../node_modules/js-joda/dist/js-joda.js:5465:41)
at SystemDefaultZoneRules.offset (.../node_modules/js-joda/dist/js-joda.js:5238:26)
at Function.ofInstant (.../node_modules/js-joda/dist/js-joda.js:1886:29)

Any ideas?

Add pattern parser/ formatter for text with locale support

Based on issue #33 implement support for text patterns with locale support for the DateTimeFormatter.

For locale database check mdn Intl.DateTimeFormat and the locale database of momentjs

flow / TypeScript type annotations / bindings

It would be nice to have flow and Typescript annotations / bindings to be able to type check the js-joda code itself but also give users the possibility to type check their usage of js-joda...
Even nicer would be if those could be generated from the esdoc comments.
Flow seems to have a way to have inline comments in e.g. function parameters but does not use the docblocks. I haven't checked for typescript yet

An in-range update of babel-loader is breaking the build 🚨

Version 6.4.1 of babel-loader just got published.

Branch	Build failing 🚨
Dependency	babel-loader
Current Version	6.4.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As babel-loader is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

---

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

• ✅ coverage/coveralls First build on greenkeeper/babel-loader-6.4.1 at 92.243% Details

Release Notes

v6.4.1

🐛 Bug Fix

• Fixed reset of BABEL_ENV when options.forceEnv is used (#420) @nikopavlica

Commits

The new version differs by 2 commits .

• 48325ea 6.4.1
• f3241f8 Fixed reset of BABEL_ENV when options.forceEnv is used (#420)

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

Why does ZonedDataTime have both _offset and _zone?

I have initialized with

import * as joda from 'js-joda'
import jstz from 'js-joda-timezone'
joda.use(jstz)

Then create a ZonedDataTime

const zdt = joda.ZonedDateTime.now(joda.ZoneId.UTC)

This zdt object has both an _offset and _zone, which are identical and both of the type ZoneOffset.

Naming

I generally consider the "joda" name at the start of a project name to be restricted to projects directly associated with me (the author of Joda-Time). When ported to other languages, developers traditionally vary the name, eg "Noda-Time" on .NET or "Soda-Time" on Scala. Thus "JS-Joda-Time" would be OK by me, although you may want to consider alternatives.

In addition, since you are porting JSR-310, rather than Joda-Time, it might be worth naming after the "threeten" name, such as "JS-ThreeTen".

Add `isAfterOrEqual` and `isBeforeOrEqual` to `LocalDate/Time`

isAfterOrEqual = !this.isBefore(other)
isBeforeOrEqual = !this.isAfter(other)

Similarly to

js-joda/test/plugTest_mochaOnly.js

Line 17 in 4a74d6e

jsJoda.LocalDate.prototype.isAfterOrEqual = function(other){

Add static `min` and `max` to `LocalDate/Time`

function min<T extends {isBefore: (_: T) => boolean}>(first: T, second: T): T {
  return first.isBefore(second) ? first : second;
}

function max<T extends {isAfter: (_: T) => boolean}>(first: T, second: T) {
  return first.isAfter(second) ? first : second;
}

Why JodaTime; why not java.time?

As you probably know, Joda-Time influenced JSR-310, which became java.time in Java 8. Several things were changed along the way, as described by Stephen Colebourne here: http://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941.html

So - is this a Joda Time port to JavaScript, or a java.time port to JavaScript? If the former, then why, considering the improvements and the young state of this port. If the latter, then the description in the readme and project page should change.

FYI - Much of my experience comes from contributing to Noda Time, which is more like java.time than it is with Joda. I'm also a collaborator on moment.js, but I've been toying with the idea of a Noda Time or java.time port to JavaScript for awhile now, so I'd be happy to help where I can.

Time zones are going to be the biggest challenge. :)

cheat sheet navigation menu side bar

Would be nice to have a menu side bar for navigating through the very long documentation of the cheat sheet at http://pithu.github.io/js-joda/cheat-sheet.html.

AT the moment we are using a half automatic process to generate the cheatsheet.html page. We maintaining the CheatSheet.md. The npm task npm run build-readme2html generates a html snippet of the md content. the snippet is manually inserted into the gh-pages/cheat-sheet.html.

One of many possible solution could be, to find a kind of self generating "table of content" javascript side menu bar library, that is generated automatically by the h tags of the dom tree.

Add iana timezone database support to js-joda

This issue is the place to discuss and plan the feature "iana tz db support" for js-joda.

The iana Time Zone Database contains data that represent the history of local time around the globe and is coordinated by the Internet Assigned Numbers Authority (IANA). The latest version of the database is provided at https://www.iana.org/time-zones.

js-joda already implements the core class for zone based date time values, ZonedDateTime, but with support for fixed zone offsets and the system default zone only. Not yet ported is the code for daylight saving transitions, compiling, compressing and providing the zone rules.

It might be not necessary to port the threeten code for compiling and compressing the tz db but instead use parts of the code of the moment timezone project http://momentjs.com/timezone/.

What is the status of DateTimeBuilder?

I see that the tests are invoking and testing _methods. Is this is not yet "released"? And also its not exported by js-joda.js.

Cleanup overloaded functions

in e.g.

• YearMonth
• MonthDay
• Year

we have overloaded functions, e.g. now(), ... the actual implementations are currently "private", i.e. their names start with _ ... but they could and should actually be public since they can be used directly and also provide the esdoc documentation... so we should make them "public" and reference their documentation from the overload function

ZoneIdFactory is missing from exports on Node 4.x

Hi.

I'm trying to use Joda in Node 4.x (4.4.5)
For some reason, some classes (including ZoneIdFactory) are missing from the module object.
I can't quite see why, though.

> require('js-joda').ZoneIdFactory
undefined

I can't import it from the source dir because of ES6 syntax.

May be compiled dist doesn't go over all the classes?

Thank you :)

Cleanup converted threetenbp Tests

we have some functions in test/testUtils.js that could be used to make the converted reference tests more similar to the original..

Cleanup the tests, e.g.

• YearMonthTest
• MonthDayTest
• MonthTest
• YearTest
• ...???

to use these functions

An in-range update of typescript is breaking the build 🚨

Version 2.0.9 of typescript just got published.

Branch	Build failing 🚨
Dependency	typescript
Current Version	2.1.1
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As typescript is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

---

Status Details

• ❌ coverage/coveralls Coverage pending from Coveralls.io Details

• ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

Commits

The new version differs by 93 commits (ahead by 93, behind by 1572).

• dcaad61 Update LKG
• 2dbbcc8 Update version
• 09f29ad add 'installSuccess' flag to telemetry, cache misses if npm install fails (#12163)
• cc81fa7 Update LKG
• 1a698df Update version
• df65cc3 Update LKG
• 435270e reduce set of files being watched, increase polling interval (#12054)
• 7c92057 enable sending telemetry events to tsserver client (#12035)
• dbf69b7 Update LKG
• 17735cd Update version
• 1b9acca use local registry to check if typings package exist (#12014)
• 4c67000 Merge pull request #11869 from Microsoft/vladima/11852
• 6041fce support both old and new set of settings in the formatting API
• 80bca64 Update LKG
• f0aa3b8 Revert "Merge pull request #11713 from Microsoft/PortSkipSemanticCheckToRelease-2-0-5" (#11802)

There are 93 commits in total. See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

Difference between `get` and `getLong`

Various js-joda classes offer both a get and a getLong method. Now I'm a bit confused.

First I thought that getLong was merely a relict from Java, where some values may not fit into a 32-bit int, but do fit into a 64-bit long. This seemed to be confirmed by classes like Instant and ZonedDateTime, where get merely calls getLong.

But then I found DayOfWeek, where get and getLong seem to do almost the same thing, but differ in exception handling. And LocalDateTime, where the two methods are implemented completely differently. Which I find rather surprising.

So what's the idea behind having these two methods?

travis is failing sometimes

I didn't change any code of the librariy itself in #28 but one test failed.
Seems that 2000ms is not enough anymore.

1) org.threeten.bp.temporal.TestIsoFields test_loop:
     Error: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.

Add pattern parser/ formatter for numbers

The js-joda release v1.0 has support for iso date/time formats such as ISO_LOCAL_DATE_TIME ('2011-12-03T10:15:30') and ISO_ZONED_DATE_TIME ('2011-12-03T10:15:30+01:00[Europe/Paris]')

Still missing is support for building a formatter/ parser by a pattern. see DateTimeFormatter.ofPattern for a description.

In a first step functionality for "number patterns" can be ported, without any support for "text patterns", so no locale text db is required.

An in-range update of eslint-plugin-promise is breaking the build 🚨

Version 3.4.1 of eslint-plugin-promise just got published.

Branch	Build failing 🚨
Dependency	eslint-plugin-promise
Current Version	3.4.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As eslint-plugin-promise is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

---

Status Details

• ❌ coverage/coveralls Coverage pending from Coveralls.io Details

• ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

Commits

The new version differs by 8 commits .

• 78b7639 3.4.1
• bb7226b Merge pull request #51 from zloirock/fix-49
• 85ffe84 add test for #49
• 81b2172 fix #49
• 803a4ab Merge pull request #45 from ascariandrea/36-rule_always_return_fails_on_import
• c931de0 Used 'node' for context.report, closes #36.
• 6f49856 Merge pull request #41 from jfmengels/fix-typo
• 6837bef Fix typo in README

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

ZoneId and subclasses to not implement toString or toJSON fully

This is related to #143 I think, where again I have problems with timezone rendering. With bunyan any object that contains a ZoneId with js-joda-timezone enabled will fail to render due to cycles, eg:

 timezone: 
   ZoneOffset {
     _totalSeconds: 0,
     _rules: Fixed { _offset: [Circular] },
     _id: 'Z' },

In #143 it was mentioned all js-joda classes implement toString() and toJSON(), but it seems this is not fully case. ZoneId delegates its toString():

toString() {
  return this.id();
}

And subclasses ZoneId do not all implement toString or toJSON like ZoneRegion and SystemDefaultZoneId and ZoneOffset.

Its this I think that was causing the issues in #143 and also causing problems when logging.

Should these classes implement at least toString?

LocalDate to LocalDate comparison via opertors

Hey,

We're trying out js-joda as a moment alternative for TypeScript. So far we like it, and have a question.

Knowing that these return the expeced results:

LocalDate.of(2017,1,10)  < LocalDate.of(2017,1,10) // false
LocalDate.of(2017,1,10) <= LocalDate.of(2017,1,10) // true
LocalDate.of(2017,1,10)  > LocalDate.of(2017,1,10) // false
LocalDate.of(2017,1,10) >= LocalDate.of(2017,1,10) // true
LocalDate.of(2016,1,10)  < LocalDate.of(2017,1,10) // true

etc.
(Note, == or === doesn't seem to be working however...)

Is it valid to compare LocalDates and the rest via operators, as it seems to be working correctly, but couldn't find it in the docs (or even where the valueOf was overridden to allow this behavior).

Thanks,
Lőrinc

IllegalArgumentException: Unknown pattern letter: d

Using js-joda 1.3.0

import {DateTimeFormatter} from 'js-joda/src/format/DateTimeFormatter';
import {LocalDate} from 'js-joda/src/LocalDate';

const dateFormatter = DateTimeFormatter.ofPattern('d MM yyyy');

Result:

    IllegalArgumentException: Unknown pattern letter: d
      
      at DateTimeFormatterBuilder._parsePattern (node_modules/js-joda/src/format/DateTimeFormatterBuilder.js:2145:1532)
      at DateTimeFormatterBuilder.appendPattern (node_modules/js-joda/src/format/DateTimeFormatterBuilder.js:2130:159)
      at Function.ofPattern (node_modules/js-joda/src/format/DateTimeFormatter.js:808:363)
      at Object.<anonymous> (src/pages/about-you/Validator.js:20:424)
      at Object.<anonymous> (src/pages/about-you/Validator.spec.js:2:44)

This is the exact pattern specified in the JSDoc, but it explodes.

Remove dependency on es6-error

As a low-level Libraty, we don't want to depend on other packages. So we need to remove the es6-error dependency and include some similar code to use ExtendableError

js-joda object to native Date object?

Hopefully I'm only overlooking it in the documentation. How do you get a native Date from a js-joda object? For example:

var jd = joda.ZonedDateTime.now().plusMinutes(30)
var d = jd.toDate() // jd.toDate is not a function

Update DateTimeFormatterPattern documentation to indicate which conversion currently work

As mentioned in #34 (comment), the current documentation of the ofPattern method mentions all patterns but does not indicate which of the patterns do not currently work due to missing locale support

We should either remove these patterns or mark them to make it clear, that they are not currently supported

Math operations

all Math operations (div, modulo, ...) we are using should be wrapped and functions in MathUtils added for them.

We expect to have problems with large integer number calculations so wrapping them now in preparation to handle big integer calculations in the future seems like a good idea

An in-range update of babel-core is breaking the build 🚨

Version 6.23.1 of babel-core just got published.

Branch	Build failing 🚨
Dependency	babel-core
Current Version	6.23.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As babel-core is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

---

Status Details

• ❌ coverage/coveralls Coverage pending from Coveralls.io Details

• ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

Why do classes implement `hashCode` methods?

I noticed that just about every js-joda class implements a hashCode method.

I know that in Java, this method is inherited from Object and is used by classes such as HashMap. However, I've never seen hashCode methods in JavaScript Code. What's more, js-joda doesn't seem to use them, either. As far as I can tell, the only places where hashCode is ever called are other hashCode implementations.

So what's the reason for these methods?

FYI - Date Proposal

Hi,

For lack of a more efficient way to contact you guys, I want you to know that I put this proposal on the agenda for the TC39 meeting next week to advance to stage 1: https://github.com/maggiepint/proposal-temporal

Your feedback along the way would be valued.

Typings don't include individual exports

For example, this is fine:

import JSJoda from 'js-joda';

const now = JSJoda.LocalDate.now();

This isn't (but is valid):

import { LocalDate } from 'js-joda';

const now = LocalDate.now();

Is there a reason for this? If not, I may be able to submit a PR to resolve this if needed.

JSJoda object is undefined in browser

When I using the v1.5 release dist/js-joda.js file was stuck, but minified version is ok.

An in-range update of webpack is breaking the build 🚨

Version 2.3.0 of webpack just got published.

Branch	Build failing 🚨
Dependency	webpack
Current Version	2.2.1
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As webpack is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

---

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

• ✅ coverage/coveralls First build on greenkeeper/webpack-2.3.0 at 92.074% Details

Release Notes

v2.3.0

Features:

• add extensions option to DllReferencePlugin
• add warningsFilter to UglifyJsPlugin to hide warnings selectively
• add extractComments to UglifyJsPlugin to move kept comments into separate file (i. e. LICENSE file)
• validate relative and absolute paths in configuration
• validate stats options
• allow to match on compiler (name in configuration) in rules
  • i. e. allows to specify different rules for extract-text-webpack-plugin or html-webpack-plugin
• Allow to pass multiple entries via CLI
• Performance improvements
• CommonsChunkPlugin give errors on incorrect options
• add module.strictExportPresence to make missing export an error instead of warning
• Compiler emits watch-close event when the watcher is closed
• Allow additional compress options in UglifyJsPlugin
• empty chunk numbers are not flags in every chunk, this improves caching invalidation

Bugfixes:

• OccurrenceOrderPlugin now counts occurrences correctly
• Fix cheap-source-maps when combined with ES Modules (lines were offset)
• Watcher now detects file deleting correctly
• Resolve output path if relative output path is given via CLI
• Handle stack traces in errors correctly
• Some usages of System now generate valid code i. e. System.global
• Dynamic property names are now parsed and can contain webpack stuff (i. e. imports)
• Empty enviroment variables are now supported in the EnvironmentPlugin
• (Maybe) Fixes chunk loading in IE when script is cached

Commits

The new version differs by 487 commits .

• 46dc08e 2.3.0
• 01c06de Merge pull request #4527 from webpack/bugfix/issue-4472
• 23e1f7c install Promise early in chunk cache
• 0c137cb Merge pull request #4521 from chicoxyzzy/patch-1
• 98ea823 Merge pull request #4503 from eirikurn/empty-env-variables
• 0058a2e Use ts-loader instead of deprecated typescript-loader
• 3e787ea Merge pull request #4502 from webpack/TheLarkInn-patch-1
• 335ce5f Merge pull request #4471 from SteveMieskoski/increase-coverage-for-AutomaticPrefetchPlugin
• fadafb2 Merge pull request #4504 from timse/do-not-merge-empty-chunks
• a9972a3 Merge pull request #4505 from rouzbeh84/hotfix/hotlinking-examples-index
• a5272e8 hotlink examples in readme
• d67e125 fix up tests
• d7ae9ad do not incorporate chunks without modules
• 003cef9 EnvironmentPlugin: Support empty env variables
• 7db849d Update README.md

There are 250 commits in total. See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

License

@pithu, @phueper -- I think it would be very helpful for this project if the two of you could agree on a license for this code and officially add it to the repo.

You've gotten a little attention recently in discussion at moment/moment#1754 (comment), and I suspect you might pick up another contributor or two from that discussion if your licensing intentions were a bit clearer. (I might be interested to contribute myself at some point, but I'm pretty swamped for at least the next month or two.)

My personal bias is that the original Joda Time got this right when they picked the Apache License -- but as the two folks who have submitted code, obviously your preferences reign supreme.

Thanks for working on this library!

to freeze or not to freeze ?

We are thinking about freezing the js-joda classes and instances with Object.freeze().

We could freeze only the class itself and there static instances like LocalTime.MIDNIGHT, so it is not possible to manipulate constant values by mistake (making bad things such as LocalTime.MIDNIGHT._hour = 24 impossible). I made some benchmark tests at https://github.com/pithu/js-joda/blob/benchmark/benchmark.js. For the v8 and the latest browsers like Chrome, Firefox, Safari, Edge it seems to have no impact on performance to freeze just the static class properties.

And we could even freeze all returned instances by js-joda. But this would have a big impact on performance. The Object.freeze operation itself is slow in all browser. In Chrome reading properties of a frozen object is faster, then reading from normal object. But in other browsers reading seems to be much slower see http://jsperf.com/object-freeze-immutable/2 and http://jsperf.com/object-freeze-immutable/4

I would argue do either freeze all or nothing. But freezing all (static class properties and all created instances) is no option because it is to slow in the most browsers.

So in my opinion we should leave it like it is and have a pseudo immutability and wait until the performance of Object.freeze improves in the most common javascript runtime engines. Other javascript libraries like Immutable.js don't freeze the objects as well.

But i am curious if there are any other opinions.

Compare notes with other threeten projects (Formatting/locale/timezone support)

Hi, I'm from https://github.com/soc/threetenbp!

We are currently investigating how to support the JSR-310 API in the browser, and two missing blocks are formatting with locale support and using a timezone database.

Did you come to any conclusions/solutions yet or are you interested in comparing notes?

Thanks,

Simon

Converting LocalDateTime back to Instant with system timezone doesn't work

When I'm trying to convert a LocalDateTime back to an Instant I'm getting an error when using the system default timezone:

JSJoda.LocalDateTime.ofInstant(JSJoda.Instant.ofEpochSecond(1000), JSJoda.ZoneId.systemDefault()).toInstant(JSJoda.ZoneId.systemDefault())

I get an error:

js-joda.min.js:13 Uncaught TypeError: t.totalSeconds is not a function(…)

When using UTC it works fine:

JSJoda.LocalDateTime.ofInstant(JSJoda.Instant.ofEpochSecond(1000), JSJoda.ZoneId.UTC).toInstant(JSJoda.ZoneId.UTC)
=>
e {_seconds: 1000, _nanos: 0}

What am I doing wrong?

An in-range update of babel-cli is breaking the build 🚨

Version 6.24.1 of babel-cli just got published.

Branch	Build failing 🚨
Dependency	babel-cli
Current Version	6.24.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As babel-cli is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

---

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

• ✅ coverage/coveralls First build on greenkeeper/babel-cli-6.24.1 at 92.074% Details

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

Missing Interval aka Range Calculation

Hi,

I noticed js-joda is missing the Interval Class from the orginal joda-time implementation.
Is there any ETA for it? We are using moment-range for overlap calculation, but we want switch to js-joda as soon as possible.

Converting milliseconds to a LocalDate

Thanks for your efforts porting Joda. A very worthy cause. However I'm a bit stuck...

I'm trying to get a local date from the a time in milliseconds. The code needs to work on developer machines running in Europe/London (and potentially other timezones), but also on a CI server and production servers running in UTC.

I've managed to get things working for just Europe/London by hard coding the ZoneOffset, but this will fail in other environments and when Europe/London moves out of daylight savings.

const zoneOffset = ZoneOffset.of('+01:00')
const today = LocalDateTime.ofEpochSecond(millis / 1000, zoneOffset).toLocalDate()

So far I haven't found a way to get the system offset using js-joda. Is this possible?

An in-range update of mocha is breaking the build 🚨

Version 3.4.0 of mocha just got published.

Branch	Build failing 🚨
Dependency	mocha
Current Version	3.3.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As mocha is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

---

Release Notes

v3.4.0

Mocha is now moving to a quicker release schedule: when non-breaking changes are merged, a release should happen that week.

This week's highlights:

• allowUncaught added to commandline as --allow-uncaught (and bugfixed)
• warning-related Node flags

🎉 Enhancements

• #2793, #2697: add --allowUncaught to Node.js (@lrowe)
• #2733: Add --no-warnings and --trace-warnings flags (@sonicdoe)

🐛 Fixes

• #2793, #2697: fix broken allowUncaught (@lrowe)

🔩 Other

• #2778: Add license report and scan status (@xizhao)
• #2794: no special case for macOS running Karma locally (@boneskull)
• #2795: reverts use of semistandard directly ([#2648]) (@boneskull)

Commits

The new version differs by 9 commits0.

• 7554b31 Add Changelog for v3.4.0
• 9f7f7ed Add --trace-warnings flag
• 92561c8 Add --no-warnings flag
• ceee976 lint test/integration/fixtures/simple-reporter.js
• dcfc094 Revert "use semistandard directly"
• 93392dd no special case for macOS running Karma locally
• 4d1d91d --allow-uncaught cli option
• fb1e083 fix allowUncaught in browser
• 4ed3fc5 Add license report and scan status

false

See the full diff

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

An in-range update of webpack is breaking the build 🚨

Version 2.3.3 of webpack just got published.

Branch	Build failing 🚨
Dependency	webpack
Current Version	2.3.2
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As webpack is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

---

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

• ✅ coverage/coveralls First build on greenkeeper/webpack-2.3.3 at 92.074% Details

Release Notes

v2.3.3

Bugfixes:

• fix progress in multi compiler

Commits

The new version differs by 2 commits .

• ba24c1b 2.3.3
• 956f618 Fix ProgressPlugin for multi compiler caused by ES6 refactoring

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴