cullophid / date-fp Goto Github PK

Get this when I use date-fp in my project:

WARNING in .//date-fp/build/date-fp.js
Critical dependencies:
1:479-486 This seems to be a pre-built javascript file. Though this is possible, it's not recommended. Try to require the original source to get better results.
@ .//date-fp/build/date-fp.js 1:479-486

Could this be added? Has it been discussed? I could perhaps take a look at it

A function that returns the current time or date, is impure because at different times it will yield different results—it refers to some global state. – source, wikipedia

Please could you add a high-level explanation to README.md that explains how date-fp enables the functionally-keen developer to safely work with date types whilst maintaining purity within their functions?

Hi, thanks for this nice lib, it is very helpful for me.

I got some problem when using get('week') as following

const date = new Date(2016, 0, 1);
D.get('week', date); // 0

According to the docs and ISO-8601,
Is this result should be 53 instead of 0 ?
Or there are some considerations ?

Many thanks!

Hello, great project! I have found it useful and wanted to contribute typescript typings. Here they are

declare module 'date-fp' {
    export function of(dateParts: number[]): Date;
    export function fromTime(time: number): Date;
    export function add(
        unit: 'milliseconds' | 'seconds' | 'minutes' | 'hours' | 'days' | 'months' | 'years',
        value: number,
        date: Date
    ): Date;
    export function clone(date: Date): Date;
    export function convertTo(
        unit: 'milliseconds' | 'seconds' | 'minutes' | 'hours' | 'days',
        date: Date
    ): number;
    export function diff(
        unit: 'milliseconds' | 'seconds' | 'minutes' | 'hours' | 'days' | 'months' | 'years',
        a: Date,
        b: Date
    ): number;
    export function equals(a: Date, b: Date): boolean;
    export function format(format: string, date: Date): string;
    export function get(
        property: 'milliseconds' | 'seconds' | 'minutes' | 'hours' | 'date' | 'day' | 'week' | 'month' | 'year',
        date: Date
    ): number;
    export function isLeapYear(date: Date): boolean;
    export function isValid(date: Date): boolean;
    export function max(dates: Date[]): Date;
    export function min(dates: Date[]): Date;
    export function parse(format: string, date: string): Date;
    export function set(
        property: 'milliseconds' | 'seconds' | 'minutes' | 'hours' | 'date' | 'week' | 'month' | 'year',
        value: number,
        date: Date
    ): Date;
    export function sub(
        unit: 'milliseconds' | 'seconds' | 'minutes' | 'hours' | 'days' | 'months' | 'years',
        value: number,
        date: Date
    ): Date;
    export function unixTime(date: Date): number;
}

For posterity.

While writing these out I noticed one function, get, is documented to return a Date but appears to return a number.

I will open a merge request to integrate these changes, but I'm having trouble building the project on my machine -- after npm install and npm run build, I see

λ npm run build    

> [email protected] build /Users/eric/workspace/github/date-fp
> npm run webpack && npm run uglify && npm run build:modules

npm WARN invalid config loglevel="notice"

> [email protected] webpack /Users/eric/workspace/github/date-fp
> webpack src/index.js build/date-fp.js --config webpack.config.js

Hash: d245f5e1c8539b1771c6
Version: webpack 1.15.0
Time: 624ms
     Asset     Size  Chunks             Chunk Names
date-fp.js  64.3 kB       0  [emitted]  main
    + 20 hidden modules
npm WARN invalid config loglevel="notice"

> [email protected] uglify /Users/eric/workspace/github/date-fp
> uglifyjs build/date-fp.js -o build/date-fp.min.js --source-map build/date-fp.min.map -p relative

Supported options:
  content         null
  filename        null
  includeSources  false
  root            null
  url             null
ERROR: `build/date-fp.min.map` is not a supported option
    at DefaultsError.get (eval at <anonymous> (/Users/eric/workspace/github/date-fp/node_modules/uglify-js/tools/node.js:18:1), <anonymous>:71:23)
    at fatal (/Users/eric/workspace/github/date-fp/node_modules/uglify-js/bin/uglifyjs:298:27)
    at run (/Users/eric/workspace/github/date-fp/node_modules/uglify-js/bin/uglifyjs:241:9)
    at Object.<anonymous> (/Users/eric/workspace/github/date-fp/node_modules/uglify-js/bin/uglifyjs:167:5)
    at Module._compile (internal/modules/cjs/loader.js:956:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:973:10)
    at Module.load (internal/modules/cjs/loader.js:812:32)
    at Function.Module._load (internal/modules/cjs/loader.js:724:14)
    at Function.Module.runMain (internal/modules/cjs/loader.js:1025:10)
    at internal/main/run_main_module.js:17:11

npm ERR! Darwin 18.7.0
npm ERR! argv "/usr/local/Cellar/node/12.12.0/bin/node" "/Users/eric/workspace/github/date-fp/node_modules/.bin/npm" "run" "uglify"
npm ERR! node v12.12.0
npm ERR! npm  v2.14.8
npm ERR! code ELIFECYCLE
npm ERR! [email protected] uglify: `uglifyjs build/date-fp.js -o build/date-fp.min.js --source-map build/date-fp.min.map -p relative`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] uglify script 'uglifyjs build/date-fp.js -o build/date-fp.min.js --source-map build/date-fp.min.map -p relative'.
npm ERR! This is most likely a problem with the date-fp package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     uglifyjs build/date-fp.js -o build/date-fp.min.js --source-map build/date-fp.min.map -p relative
npm ERR! You can get their info via:
npm ERR!     npm owner ls date-fp
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/eric/workspace/github/date-fp/npm-debug.log
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: `npm run webpack && npm run uglify && npm run build:modules`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/eric/.npm/_logs/2019-11-11T15_12_29_178Z-debug.log

Have I gone about building the project the right way?

I am not very familiar with any parts of this build system so it may take a prohibitive amount of time to resuscitate. I notice it has been a few years since deps were updated so things may have gotten a bit wonky. Any guidance would be appreciated

Thanks again for date-fp!

I have the following compose implementation:

compose = (...fns) => data => fns.reduceRight((value, func) => func(value), data);

I am quite new to functional programming and want to compose get('day') and sub('days'):

const { get, sub, format } = require('date-fp');

const previousSunday = compose(sub('days'), get('day'));

const date = new Date();

Now if I call previousSunday(date), it returns a (curried?) get('day', n) function (n being the value returned from sub()), which I have to call again with a date argument, e. g. previousSunday(date)(date).

How can I compose those functions in a way that I only have to pass the date once? I eventually want to compose that with format() as well, i. e.:

const previousSundayThisWeek = previousSunday(date);
const formatPreviousSunday = compose(format('YYYY-MM-DD'), previousSundayThisWeek);
const sunday = formatPreviousSunday(date);

I would rather want to compose all those functions so that I can only pass the date once, but I can't see how to compose them properly. Something like...

const previousSunday = compose(format('YYYY-MM-DD'), sub('days'), get('day'))(date);

wouldn't work of course.

Any help or hints are greatly appreciated. Thanks!

Eg. D.add('weeks', 1, new Date()) and D.sub('weeks', 1, new Date()).

Dear Mr robot,
Firstly, thanks for taking the time to write this lib, it is a good idea and has a nice, clean interface.

I hope that this testing is useful to you - I realise that it a little sparse but the following is what I consistently get with different dates. I believe it is because the string names expected in the setters here are date, month and year rather than the days, months and years suggested in the docs below.

I have tested this using the example code in the Docs here: https://evilcorp.limited/date-fp/docs/functions/set.html

These are my results:
`
var date = new Date('2001-01-01 01:01:01.0');
// Mon Jan 01 2001 01:01:01 GMT+0000 (GMT)

var y = D.set('milliseconds', 123, date);
// Mon Jan 01 2001 01:01:01 GMT+0000 (GMT)

var y = D.set('minutes', 13, date);
// Mon Jan 01 2001 01:13:01 GMT+0000 (GMT)

var y = D.set('seconds', 13, date);
// Mon Jan 01 2001 01:01:13 GMT+0000 (GMT)

var y = D.set('hours', 13, date);
// Mon Jan 01 2001 13:01:01 GMT+0000 (GMT)

var y = D.set('days', 13, date);
// Invalid Date

var y = D.set('months', 1, date);
// Invalid Date

var y = D.set('years', 2015, date);
// Invalid Date

// === TEST THEORY === //
var y = D.set('year', 2015, date);
// Thu Jan 01 2015 01:01:01 GMT+0000 (GMT)
`
Tested in Chrome Canary only.

Hi, thanks for this awesome lib. I use it in my current project happily.

I find out there is no get('Day') currently which supports to get a weekday from a Date instance, like what Date.prototype.getDay does.

I am not sure it is a good idea to add this feature to this lib. If it looks good to you, I would like to create a PR for it.

On my local machine, the test for get timezoneOffset fails

  1) get should return timezoneOffset:

      AssertionError: -60 == -120
      + expected - actual

      --60
      +-120

I suspect that summer time is the problem here. If I change the input date from January to June the test will pass which means that getTimeZone returns the offset in my current timeZone at the specific time of the date.

We can change the test so that the input date always have the same offset as the date being tested. Either way, this is new information to me.

Hello @cullophid
There's no timezone-related functionalities
I can help with that :)

Hey, it would be cool, if .format() could be expanded in such a way that one could add time zones, so that the resulting string would become a ISO 8601 compliant zoned date time like

2018-07-30T04:44:42+02:00

format may return different values depending on who uses it or where.

For me, living in Sweden, format('HH:mm', new Date(0)) === '01:00'. It really should be '00:00'. I suspect that people from different parts of the world will have varying results.

Thoughts?

Add simple i18n support

Looks like something is up with the documentation website

Say a user does something silly like this:

D.format('B', new Date())
// => 'B'

Obviously this output is as nonsensical as the input but how - or even, should - we guard against this happening? What is the appropriate response here when we can't throw an error. Should we just return the string Invalid Date?

Hello.
I very much like the idea of this project but I was unable to run this in node due to some build problems. Mainly the build folder was not included in the package. I also found some other room for improvement. I could fix all of these but would like to check first:

• The built files are included in source control, remove?
• Add the files and directories that should be included in the npm package in "files" in package.json
• Add source maps
• Export the module to umd format which will make it usable in node, require-js or globally in the browser.

I can easily fix all these unless there is any objection

date-fp is published as a single build file, which forces consumers to required all functions in their bundles.

Maybe we can also release separated compiled-to-ES5 files, and consumers can required the only functions they need.

I would like to implement this if it looks good to you :)

Currently the library has no functionality related to time zones.

• what functionality do we need?