Skip to content

Derive generic instances for Data.Date.Date and all types in Data.Time #22

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

wereHamster
Copy link

No description provided.

@wereHamster wereHamster force-pushed the derive-generic branch 2 times, most recently from 2e54477 to 5391ac1 Compare November 10, 2015 08:38
@garyb
Copy link
Member

garyb commented Nov 10, 2015

I don't think we can make a valid generic instance for this as it is a native type. That was @paf31's assertion in #19 at least.

@wereHamster
Copy link
Author

I'm not representing a Date as a string but as a product with one constructor, and the millisecond value of the date object. I believe that's what derive would do if Date were a newtype around Millisecond.

Actually, why not make Date as a newtype around Millisecond instead of carrying around the native JSDate? If that were the case then we could automatically derive Generic! What would be the downsides?

@garyb
Copy link
Member

garyb commented Nov 10, 2015

That sounds like a good idea to me! It gets rid of the potential mutability of the date value too then 👍

We'd also need to keep a time offset with it too I think perhaps? That's good too though, as currently the timezone/offset support is Not Good.

@wereHamster
Copy link
Author

FYI, I'm not using this module anymore (we switched away from PureScript, unfortunately). So if somebody wants to take over this pull request feel free to.

@FrigoEU
Copy link

FrigoEU commented May 5, 2016

@garyb what offset/timezone support do you think would be most beneficial? Is it the plan here to incorporate this whole body of (notoriously tricky) offset/timezone logic like a library like moment.js does?

Would it be a possibility to merge this PR as it is now and hold off on the move to a newtype around Milliseconds + timezone/offset? Or do you think that's a bad idea?

@wereHamster Am I correct in assuming that this PR is pretty complete as is, apart from the possible migration to a newtype around milliseconds + timezone/offset for the Date type?

@wereHamster
Copy link
Author

@FrigoEU I think it's complete and can be merged. It certainly doesn't break any existing code and generic instance for Date is sound IMO.

@FrigoEU
Copy link

FrigoEU commented May 5, 2016

I did notice that there's some Generic Instances missing for Year, DateOfMonth, etc. I could do that work, but tbh I have no idea how to take over a PR :).

I agree with the current Generic instance for Date being sound.

@wereHamster
Copy link
Author

@FrigoEU I think the best way is if I close this one and you open a new one.

@wereHamster wereHamster closed this May 5, 2016
@FrigoEU
Copy link

FrigoEU commented May 5, 2016

Okido, will do.

@FrigoEU FrigoEU mentioned this pull request May 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants