🕑 js-joda is an immutable date and time library for JavaScript.

Overview

Immutable date and time library for JavaScript

Tested node version lerna Build Status Sauce Test Status Coverage Status

Sauce Test Status

Introduction

js-joda is an immutable date and time library for JavaScript. It provides a simple, domain-driven and clean API based on the ISO8601 calendar.

  • js-joda supports ECMAScript 5 browsers down to IE9.

  • js-joda is a port of the ThreeTen backport, which is the base for JSR-310 implementation of the Java SE 8 java.time package. Threeten is inspired by Joda-Time, having similar concepts and the same author.

  • js-joda is robust and stable. We ported more then 1700 test-cases with a lots of test-permutations from the ThreeTen Backport project. We run the automated karma test-suite against Firefox, Chrome, Node and phantomjs.

js-joda packages

js-joda consist of four packages:

package name description path
@js-joda/core Implementation of the ThreeTen Classes and API /packages/core
@js-joda/timezone Implementation of timezone calculation based on the iana Time Zone Database /packages/timezone
@js-joda/locale Implementation of locale specific functionality for js-joda, especially for formatting and parsing locale specific dates /packages/locale
@js-joda/extra Implementation of the ThreeTen-Extra Classes and API /packages/extra

The @js-joda/examples package is for testing the different build artifacts in different context, like webpack, browser node, etc.

js-joda is now a mono repo

We moved all js-joda libraries into this repository as a monorepo and put all js-joda npm modules under the @js-joda scope.

The previous repositories for the packages js-joda-timezone, js-joda-locale and js-joda-extra are deprecated.

The last version of previous packages and the equivalent new scoped package versions are as follows:

last version of previous package equivalent new scoped package
[email protected] @js-joda/[email protected]
[email protected] @js-joda/[email protected]
@js-joda/[email protected]+34.0.0 @js-joda/[email protected]+34.0.0
[email protected] @js-joda/[email protected]

Links

Comments
  • Update rollup to the latest version 🚀

    Update rollup to the latest version 🚀

    Version 0.63.5 of rollup was just published.

    Dependency rollup
    Current Version 0.62.0
    Type devDependency

    The version 0.63.5 is not covered by your current version range.

    If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

    It might be worth looking into these changes and trying to get this project onto the latest version of rollup.

    If you have a solid test suite and good coverage, a passing build is a strong indicator that you can take advantage of these changes directly by merging the proposed change into your project. If the build fails or you don’t have such unconditional trust in your tests, this branch is a great starting point for you to work on the update.


    Commits

    The new version differs by 36 commits.

    • dc9f347 0.63.5
    • 6c1d1e6 Fix typings for turbo color
    • e109576 Update changelog
    • 115239f Update changelog
    • da97ea5 Add plugin implemenation type (#2355)
    • 55d90d8 fix regression #2305, ensure onwrite plugin hooks execute in sequence (#2364)
    • fc1e6f7 Update changelog
    • d07d5bf Always warn when no name is provided for a global module (#2359)
    • 489477d Update changelog
    • 9eaa1d9 Remove "es6" output format from types (#2349)
    • 382323a fix(types): inlineDynamicImports is optional (#2348)
    • 738f2fc 0.63.4
    • e9854a7 Update changelog
    • aa3ad1d feat: swap chalk→turbocolor (#2339)
    • d6c3ea8 0.63.3

    There are 36 commits in total.

    See the full diff

    FAQ and help

    There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


    Your Greenkeeper bot :palm_tree:

    greenkeeper 
    opened by greenkeeper[bot] 47
  • Disallowing implicit conversion of Temporal/TemporalAmount to numeric values

    Disallowing implicit conversion of Temporal/TemporalAmount to numeric values

    This PR is an experiment that implements a function Temporal.prototype.valueOf that always throws as discussed in #157. If the idea is accepted I still think the same should apply to TemporalAmount and maybe TemporalAccessor.

    As you can see in the changes any implicit coercion throws, including something like temporal + "string". The reason is that operator + calls valueOf() if it exists and only calls toString() if it doesn't, even if the RHS argument is a string. In those cases is necessary to even explicitly convert to string (using .toString() or String()) or use a string context (like strings using backticks).

    What are your thoughts on this?

    EDIT: Finally the decision was not to use valueOf but Symbol.toPrimitive so implicit coercion to string is still allowed. This has some implications:

    • It doesn't work in < ES6, so the coercion won't throw in ES5 environments. Since those should be a minority it was decided to just go with it.
    • Adding two Temporals together (or TemporalAmount) using operator + won't throw, instead both sides of the operation will be converted to string and concatenated. This includes, for instance, LocalDate.now() + 99 which will yield something like "2021-10-3199". This is the usual behavior in EcmaScript; hardening it will prevent handy concatenation between string and Temporal objects, which might be too much of a breaking change.
    • It will throw, however, in cases like using operators <, >= or the unary +.
    enhancement breaking 
    opened by InExtremaRes 23
  • extra types

    extra types

    This PR adds:

    • LocalDateRange,
    • OffsetDate,
    • Quarter,
    • YearQuarter,
    • YearWeek.

    It was necessary to modify ChronoField.EPOCH_DAY.range() (which was incorrect), otherwise LocalDate.MIN.toEpochDay() and LocalDate.MAX.toEpochDay() was outside of it.

    It was also neccessary to mark ChronoField.PROLEPTIC_MONTH to be date-based as OffsetDate tests depend on that.

    I wasn't sure how to include these 2 changes into compilation process with no ability to publish core, so locally I used npm link ../core. It's possible that CI build will fail. What is the preferred way to deal with such inter-module dependencies?

    In 2 places I've used generator functions to imitate streams, so @babel/plugin-transform-regenerator is now required.

    enhancement 
    opened by perceptron8 22
  • New TS types for locale package

    New TS types for locale package

    As discussed in #386, this is my proposal.

    The relevant points:

    1. The Locale type is no longer in core since has no use without a locale imported.
    2. The locale module add a Locale class that can be imported.
    3. When the locale module is imported the module '@js-joda/core' is augmented, adding the withLocale method to DateTimeFormatter and other locale specific methods.

    As you can see in the test, it just works. If you comment the line import { Locale } from '../..'; in the test, then TS fails since the methods withLocale, appendText, etc. are not known.

    I have no much experience with packaging and publishing so maybe there is more work needed.

    I added types for DateTimeFormatterBuilder.prototype.appendWeekField() but couldn't find test for it. Is this method part of the public API? Are the types correct?

    opened by InExtremaRes 22
  • Update rollup to the latest version 🚀

    Update rollup to the latest version 🚀

    The devDependency rollup was updated from 0.62.0 to 1.12.4.

    This version is not covered by your current version range.

    If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.


    Release Notes for v1.12.4

    2019-05-27

    Bug Fixes

    • Show correct error stack trace for errors throw in "load" hooks (#2871)

    Pull Requests

    Commits

    The new version differs by 399 commits.

    • d4ce506 1.12.4
    • bc709ad Update changelog
    • 00cfcb7 Mention subfolders in docs (#2875)
    • 941e822 Reserve error stack information (#2871)
    • 455e994 1.12.3
    • c72da4a Update changelog
    • 9f84980 Properly deduplicate reexported default exports (#2866)
    • 0655489 Update changelog
    • 65b6aef Enable TypeScript strictNullChecks (#2755)
    • a4fbc53 1.12.2
    • 968cb2a Update changelog
    • 72f2e81 Cache transitive reexport detection (#2864)
    • 020e87f Update changelog
    • 7aaec61 Declare processConfigsErr before use (#2858)
    • 6a79bc1 keep nested exports with preserveModules (#2854) (#2863)

    There are 250 commits in total.

    See the full diff

    FAQ and help

    There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


    Your Greenkeeper bot :palm_tree:

    greenkeeper 
    opened by greenkeeper[bot] 21
  • An in-range update of webpack is breaking the build 🚨

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

    Version 4.13.0 of webpack was just published.

    Branch Build failing 🚨
    Dependency webpack
    Current Version 4.12.2
    Type devDependency

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

    webpack is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

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

    Release Notes v4.13.0

    Features

    • the DefinePlugin now supports runtimeValues to pass computed values with dependencies that can change over time
    • added optimization.hashedModuleIds
    • crossOrigin for chunks is only set when really needed
    • added per chunk group indicies
    • updated enhanced-resolve
      • You can now use absolute paths as keys to resolve.alias

    Bugfixes

    • when delegating CLI the bin fields are used
    • when assigning indicies sync dependencies are now walked before async dependencies
    Commits

    The new version differs by 52 commits.

    • e3678aa 4.13.0
    • 43563b3 hotfix merge issue in watchCases (not in CI)
    • 09beba0 Merge pull request #7621 from webpack/deps/enhanced-resolve
    • 7b7d323 upgrade enhanced-resolve
    • 34b0c7c Merge pull request #6906 from stepharr/patch-1
    • b181bc4 Merge pull request #6793 from ronkorving/define-functions
    • e08399a Merge pull request #7017 from rtsao/crossorigin-attr
    • b848ec5 Merge pull request #6346 from Connormiha/simplife-has-dependencies
    • 8420c73 Merge branch 'master' into define-functions
    • ef2ec25 update template.md too
    • 5c4ffd5 fix tests and code
    • 6478fb9 Merge branch 'master' into crossorigin-attr
    • dcf3e09 Merge pull request #7399 from webpack/feat-implement-option-for-hashed-module-ids-plugin
    • f41b829 Merge pull request #7604 from webpack/feature/update-snapshot-script
    • 17fa26c use jest directly

    There are 52 commits in total.

    See the full diff

    FAQ and help

    There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


    Your Greenkeeper Bot :palm_tree:

    greenkeeper 
    opened by greenkeeper[bot] 21
  • Add pattern parser/ formatter for text with locale support

    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

    opened by pithu 21
  • Can js-joda parse

    Can js-joda parse "UTC strings" out of the box?

    It appears that there is an old date/time representation format, sometimes referred to as "UTC string". It was originally specified in RFC 7321 (HTTP/1.1 Semantics and Content). String in this format are returned by Date.prototype.toUTCString.

    ECMAScript standard does not require Date.parse to support this format.

    The function first attempts to parse the String according to the format described in Date Time String Format (20.3.1.15), including expanded years.

    (Date Time String Format (20.3.1.15) means ISO 8601-like, e.g. 1995-02-05T00:00)

    If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.

    It seems that, in practice, some popular JavaScript implementations decide to support "UTC string" as one of implementation-specific date formats. It kind of makes sense, as it mirrors toUTCString. I haven't found any documentation to support this, though. It can be verified empirically. Unfortunately, depending on such implementation-specific behaviour is not portable or guaranteed to be forward-compatible, especially when the implementation-specific behaviour is undocumented.

    What is more, MDN recommends to use third-party libraries to parse implementation-specific date formats like "UTC string":

    It is not recommended to use Date.parse as until ES5, parsing of strings was entirely implementation dependent. There are still many differences in how different hosts parse date strings, therefore date strings should be manually parsed (a library can help if many different formats are to be accommodated).

    Strings in "UTC string" format are returned at least by Node.js Firebase Admin Auth, but probably many more.

    Is there a simple way to parse "UTC strings" using js-joda? I've searched the API and the source code, without success.

    bug 
    opened by cubuspl42 20
  • An in-range update of webpack is breaking the build 🚨

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

    The devDependency webpack was updated from 4.20.2 to 4.21.0.

    🚨 View failing branch.

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

    webpack is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

    Status Details
    • continuous-integration/travis-ci/push: The Travis CI build failed (Details).
    • coverage/coveralls: First build on greenkeeper/webpack-4.21.0 at 92.517% (Details).

    Release Notes for v4.21.0

    Features

    • add output.libraryTarget: "amd-require" which generates a AMD require([], ...) wrapper instead of a define([], ...) wrapper
    • support arrays of strings passed to output.library, which exposes the library to a subproperty

    Bugfixes

    • fix cases where __webpack_require__.e is used at runtime but is not defined in the bundle
    • fix behavior of externals of global type

    Performance

    • Some performance improvements to the chunk graph generation
    Commits

    The new version differs by 37 commits.

    • 432d2a3 4.21.0
    • 0fb6c60 Merge pull request #7038 from marcusdarmstrong/marcusdarmstrong-external-module-fix
    • 15b6f8b make afterEach async
    • 7bc5c98 Merge branch 'master' into marcusdarmstrong-external-module-fix
    • 2228daf Merge pull request #8230 from webpack/revert-8120-rh-silent-reporter
    • fadf875 remove dependency
    • 7c0b209 Revert "Re-enable jest-silent-reporter #hacktoberfest"
    • a868789 Merge pull request #8143 from MLoughry/miclo/optimize-chunk-graph-generation
    • 1d71ede Make changes suggested by @sokra to optimize chunk graph generation
    • 4d3fe00 Merge pull request #8134 from fscherwi/update-coveralls
    • 86f56bf update coveralls
    • 4c461e2 Merge pull request #8120 from rickhanlonii/rh-silent-reporter
    • 9fe42e7 Merge pull request #8118 from webpack/bugfix/issue-8110
    • 0b6ad2a Don't be clever with the set command because idk windows
    • 148016e Rerun yarn

    There are 37 commits in total.

    See the full diff

    FAQ and help

    There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


    Your Greenkeeper Bot :palm_tree:

    greenkeeper 
    opened by greenkeeper[bot] 20
  • Improve of the TS declarations

    Improve of the TS declarations

    This PR fix the TypeScript declarations, improving a little the type safety and hiding some non-public functions.

    • Some parameters and return values previously typed as any now get a more specific type. There is more work to do here, but this change, even if small, is an improvement.

    • ~The previous point is more noticeable in the equals methods that are now typed to only accept the same instance than the class they are declared. I am aware that equals accepts any value and returns false when the type doesn't match, but I think most of the time it is a non-intentional developer mistake to compare values of different types; in the rare cases it is the developer intention to do that (for example to pick a value from an array of Temporal), the "unsafe" comparison can be expressed explicitly with something like value.equals(other as any) or similar.~

      Edit: As requested, now every equal method has a single parameter of type any.

    • Some static methods were not intended to be public so they're removed from the declarations. Some others got a parameter name fixed or were marked as optional.

    • The declaration file is now explicitly declared as an ES module. This is perhaps the most important change of this PR so I will explain in detail below.

    • Declaration file for the extra package is now an ES module also and uses the types of core correctly.

    • Some new methods are typed, like Year.

    • File is also formatted, mostly automatically.

    The way the file was written, with a declare namespace JSJoda and an export = JSJoda, is a common pattern for CommonJS modules. It works but is not very precise since the distributed .js file is build as an ES module and doesn't include a default export. For instance TypeScript will not fail at compile time if we import the library like this (assuming esModuleInterop: true):

    import joda from '@js-joda/core';
    

    Even more, TS suggests to convert this, which is valid:

    import * as joda from '@js-joda/core';
    

    to the former type of import.

    The file is now using a more common pattern for modules that only have named exports and the __esModule: true property informs TS that this is an ES module so it cannot be converted to a default import even if esModuleInterop is set. That property is automatically defined by Babel.

    I make every change in a different commit so it would be easy to split this in two or more different PRs if you are happy with only some of the changes.

    Closes #349, closed #347

    opened by InExtremaRes 18
  • Add iana timezone database support to js-joda

    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/.

    opened by pithu 16
  • Interval.parse hangs/fails

    Interval.parse hangs/fails

    Interval.parse('2022-12-07T18:55:57.651Z/+1000000-12-31T23:59:59.999999999Z')
    

    hangs. This was created by

    `${Interval.of(Instant.now(), Instant.MAX)}`
    

    takes a very long time to get to this stack trace

        DateTimeParseException: Text '+1000000-12-31T23:59:59.999999999Z' could not be parsed: Invalid int value for Year: 1000000: +1000000-12-31T23:59:59.999999999Z, at index: 0
        -------
        Caused by: DateTimeException: Invalid int value for Year: 1000000
    
          12 |   params: TransformFnParams,
          13 | ): Interval {
        > 14 |   return Interval.parse(params.value);
             |                   ^
          15 | }
          16 |
          17 | export function transformIntervalToString(params: TransformFnParams): string {
    
          at ValueRange.checkValidIntValue (../../node_modules/@js-joda/core/src/temporal/ValueRange.js:135:19)
          at ChronoField.checkValidIntValue (../../node_modules/@js-joda/core/src/temporal/ChronoField.js:307:29)
          at IsoChronology.resolveDate (../../node_modules/@js-joda/core/src/chrono/IsoChronology.js:115:48)
          at DateTimeBuilder._mergeDate (../../node_modules/@js-joda/core/src/format/DateTimeBuilder.js:174:48)
          at DateTimeBuilder.resolve (../../node_modules/@js-joda/core/src/format/DateTimeBuilder.js:149:14)
          at DateTimeFormatter.parse2 (../../node_modules/@js-joda/core/src/format/DateTimeFormatter.js:491:62)
          at DateTimeFormatter.parse (../../node_modules/@js-joda/core/src/format/DateTimeFormatter.js:439:25)
          at Function.parse (../../node_modules/@js-joda/core/src/ZonedDateTime.js:485:26)
          at Function.parse (../../node_modules/@js-joda/extra/src/Interval.js:137:47)
          at Object.transformIntervalToInstance [as transformFn] (../../libs/core/src/utilities/time.ts:14:19)
          -------
          at DateTimeFormatter._createError (../../node_modules/@js-joda/core/src/format/DateTimeFormatter.js:509:16)
          at DateTimeFormatter.parse2 (../../node_modules/@js-joda/core/src/format/DateTimeFormatter.js:497:28)
          at DateTimeFormatter.parse (../../node_modules/@js-joda/core/src/format/DateTimeFormatter.js:439:25)
          at Function.parse (../../node_modules/@js-joda/core/src/ZonedDateTime.js:485:26)
          at Function.parse (../../node_modules/@js-joda/extra/src/Interval.js:137:47)
          at Object.transformIntervalToInstance [as transformFn] (../../libs/core/src/utilities/time.ts:14:19)
          at ../../node_modules/src/TransformOperationExecutor.ts:412:24
              at Array.forEach (<anonymous>)
          at TransformOperationExecutor.applyCustomTransformations (../../node_modules/src/TransformOperationExecutor.ts:411:15)
          at TransformOperationExecutor.transform (../../node_modules/src/TransformOperationExecutor.ts:334:33)
    
    opened by xenoterracide 3
  • Feature request: Add time zone dist splits to @js-joda/timezone

    Feature request: Add time zone dist splits to @js-joda/timezone

    Would it be feasible to, in addition to the current year-range splits, add a split by individual time zones in @js-joda/timezone?

    This would drastically reduce the imported data when only one or a few time zones need to be supported in an app while also covering all years for which there is time zone data.

    The imports could look like this: import '@js-joda/timezone/dist/js-joda-timezone-Europe_Berlin'.

    opened by idrm 0
  • Incorrect timezone parsing for dates in the far future

    Incorrect timezone parsing for dates in the far future

    I've noticed dates in London timezone are being parsed differently between '2022-04-22T15:00:00' and '2038-04-22T15:00:00'.

    LocalDateTime.parse( '2022-04-22T15:00:00', DateTimeFormatter.ISO_LOCAL_DATE_TIME ) .atZone(ZoneId.of('Europe/London')) .format(DateTimeFormatter.ISO_INSTANT) => '2022-04-22T14:00:00Z' (correct)

    LocalDateTime.parse( '2038-04-22T15:00:00', DateTimeFormatter.ISO_LOCAL_DATE_TIME ) .atZone(ZoneId.of('Europe/London')) .format(DateTimeFormatter.ISO_INSTANT) => '2038-04-22T15:00:00Z' (incorrect?)

    Is this a bug? JS Date and other apps like Google Calendar parse '2038-04-22T15:00:00' (London timezone) to '2038-04-22T14:00:00Z' which is different from js-joda.

    opened by dhassaine 5
  • Why `isEqual` and `compareTo` can't deal with null values?

    Why `isEqual` and `compareTo` can't deal with null values?

    I'm wondering if there is any reason why isEqual and compareTo can't deal with null values. We have a use case where we need localDateTime.isEqual(null) to return false rather than cause an error, and we don't have control over the call to localDateTime.isEqual. We can provide more info about our use case if you're interested.

    We currently overcome this issue by creating another class that extends LocalDateTime and there we override the method like this:

      isEqual(other) {
        return !!other && super.isEqual(other);
      }
    

    It will be more elegant if we can change the isEqual method in the LocalDateTime to:

       isEqual(other) {
            return !!other && this.compareTo(other) === 0;
        }
    

    Please let me know if you can consider merging such a change in the code, I'll be happy to create a PR.

    opened by stevcooo 6
  • add AmountFormats from threeten-extra

    add AmountFormats from threeten-extra

    This does human readable formatting of amounts of time

    https://www.threeten.org/threeten-extra/apidocs/org.threeten.extra/org/threeten/extra/AmountFormats.html

    opened by henryw374 0
  • TypeError: Cannot add property x, object is not extensible

    TypeError: Cannot add property x, object is not extensible

    Hi. I have an issue using ZoneId.of().

    When I define and export ZoneId.of() in a Utility class as a const, and import and use this ZoneId.of() in another class then I get this stacktrace:

    core.mjs:6485 ERROR TypeError: Cannot add property 89, object is not extensible at LDTUntils._getTupple (js-joda-timezone.js:1093:1) at LDTUntils.get (js-joda-timezone.js:1100:1) at ldtBinarySearch (js-joda-timezone.js:1114:1) at MomentZoneRules._offsetInfo (js-joda-timezone.js:960:1) at MomentZoneRules.validOffsets (js-joda-timezone.js:986:1) at Function.ofLocal (js-joda.esm.js:9028:1) at Function.of2 (js-joda.esm.js:9010:1) at Function.of3 (js-joda.esm.js:9006:1) at Function.of (js-joda.esm.js:8999:1) at ExampleComponent.onFormSubmit (example.component.ts:202:27)

    Is there any reason why this issue occurs? This error does not occur always!

    In my Utility class, I define the zoneId as follows:

    
    export const defaultZoneId = ZoneId.of('Europe/Amsterdam');
    export class DateUtil {
    }
    
    

    And finally I import and use this ZoneId.of() in another class

    
    import { defaultZoneId } from '../util/date-util';
    
    export class ExampleComponent {
    
       public onFormSubmit(form): void {
     
             const zonedDateTime = ZonedDateTime.of(localDate, localTime, defaultZoneId);
              ....
       }
    
    }
    
    
    opened by petereijgermans11 1
Releases(@js-joda/[email protected]+36.0.0)
⏰ Day.js 2kB immutable date-time library alternative to Moment.js with the same modern API

English | 简体中文 | 日本語 | Português Brasileiro | 한국어 | Español (España) | Русский Fast 2kB alternative to Moment.js with the same modern API Day.js is a

null 41.7k Dec 28, 2022
Duet Date Picker is an open source version of Duet Design System’s accessible date picker. Try live example at https://duetds.github.io/date-picker/

Duet Date Picker Duet Date Picker is an open source version of Duet Design System’s accessible date picker. Duet Date Picker can be implemented and us

Duet Design System 1.6k Jan 6, 2023
Create Persian Calendar as html helper with tag builder c# , and convert selected persian date to gregorian date

Persian-Calendar Use JS,Html,CSS,C# White theme for Persian Calendar , easy to use. Create Persian Calendar as html helper. Use Tag builder in c# for

Tareq Awwad 4 Feb 28, 2022
A date picker web component, and spiritual successor to duet date picker

<date-picker> A date picker web component, based on duet date picker, except authored with Lit and using shadow DOM. This is a work in progress. Todo:

Nick Williams 25 Aug 3, 2022
:clock8: :hourglass: timeago.js is a tiny(2.0 kb) library used to format date with `*** time ago` statement.

timeago.js timeago.js is a nano library(less than 2 kb) used to format datetime with *** time ago statement. eg: '3 hours ago'. i18n supported. Time a

hustcc 4.9k Jan 4, 2023
⏳ Modern JavaScript date utility library ⌛️

date-fns provides the most comprehensive, yet simple and consistent toolset for manipulating JavaScript dates in a browser & Node.js. ?? Documentation

date-fns 30.6k Dec 29, 2022
CalendarPickerJS - A minimalistic and modern date-picker component/library 🗓️👨🏽‍💻 Written in Vanilla JS

CalendarPickerJS The simple and pretty way to let a user select a day! Supports all major browser. Entirely written in Vanilla JavaScript with no depe

Mathias Picker 15 Dec 6, 2022
This library provide a fast and easy way to work with date.

Calendar.js Calendar.js provide a fast way to work with dates when you don't wanna deal with hours, minute, second and so on. It means that Calendar.j

ActuallyNotaDev 3 Apr 27, 2022
A tiny and fast zero-dependency date-picker built with vanilla Javascript and CSS.

A tiny zero-dependency and framework-agnostic date picker that is incredibly easy to use! Compatible with any web UI framework, vanilla JS projects, and even HTML-only projects!

Nezar 1 Jan 22, 2021
DEPRECATED: Timezone-enabled JavaScript Date object. Uses Olson zoneinfo files for timezone data.

TimezoneJS.Date A timezone-enabled, drop-in replacement for the stock JavaScript Date. The timezoneJS.Date object is API-compatible with JS Date, with

Matthew Eernisse 830 Nov 20, 2022
Lightweight and simple JS date formatting and parsing

fecha Lightweight date formatting and parsing (~2KB). Meant to replace parsing and formatting functionality of moment.js. NPM npm install fecha --save

Taylor Hakes 2k Jan 5, 2023
Reusable date picker component for React

React DayPicker DayPicker is a reusable date picker component for React. $ npm install react-day-picker@next Beta version ⚠️ This branch is for the ne

Giampaolo Bellavite 4.8k Dec 28, 2022
Date() for humans

date Date is an english language date parser for node.js and the browser. For examples and demos, see: http://matthewmueller.github.io/date/ Update: d

Matthew Mueller 1.5k Jan 4, 2023
A lightweight, locale aware formatter for strings containing unicode date tokens.

Date Token Format A lightweight (~2kB), locale aware formatter for strings containing unicode date tokens. Usage Install the package using: yarn add d

Donovan Hutchinson 1 Dec 24, 2021
Nepali Date Picker jQuery Plugin 🇳🇵

Nepali Date Picker Nepali Date Picker jQuery Plugin for everyone. ???? Installation npm install nepali-date-picker Demo and Documentation https://leap

Leapfrog Technology 70 Sep 29, 2022
React Native Week Month Date Picker

React Native Week Month Date Picker Date picker with a week and month view Installation npm install react-native-week-month-date-picker Dependencies T

Noona 119 Dec 27, 2022
Easy to get a date.

date2data 테이블에 날짜별 데이터 넣을 때마다 새로 객체 만들어서 작업하기가 매우 귀찮아서 만들었다. moment.js를 쓰기에는 구현하고자 하는 내용이 너무 가벼웠음 Install npm i date2data Usage import {getMonthlyDate

Duho Kim 3 Apr 12, 2022
A lightweight javascript timezone library

Isn't it weird how we can do math in our head, but not date math? how many days until the end of the year? what time was it, 11 hours ago? is it lunch

spencer kelly 3.7k Dec 29, 2022
⏱ A library for working with dates and times in JS

Luxon Luxon is a library for working with dates and times in JavaScript. DateTime.now().setZone("America/New_York").minus({ weeks: 1 }).endOf("day").t

Moment.js 13.4k Jan 9, 2023