Non FFI version of purescript-datetime

[Cmdv]

After a brief chat with @garyb here, it was mentioned that ideally purescript-datetime could actually be 100% pure Purescript.

Would the idea be to reproduce these specs here?

As a starting point I assume I'd need to replace:

var createDate = function (y, m, d) {
  var date = new Date(Date.UTC(y, m, d));
  if (y >= 0 && y < 100) {
    date.setUTCFullYear(y);
  }
  return date;
};

So there would be no leaning on the use of JS's implementation? This is assuming I'm not barking up the wrong tree, if that is the case what might one need to look at?

edit: I'm also looking at Haskell's Date.Time for guidance.

[garyb]

Ooh, nice find. One of the reasons I didn't do it, is I didn't have a handy reference of the rules. That looks like a great resource!

Perhaps we should create and add them as tests first, just testing the current version, merge that, and then yeah can start replacing the FFI functions with pure implementations. :+1:

[Cmdv]

ah yeah that a much better plan than jump in replace everything lol.

I'll set up some test to try mimic the specs 😄

[Cmdv]

After looking deeper into this, I'm finding it difficult to see the current implementation reflecting the ecma specs. Looking at the function Weekday:

Day(t) = floor(t / msPerDay)
msPerDay = 86400000

WeekDay(t) = (Day(t) + 4) modulo 7
 A weekday value of
   0 specifies Sunday;
   1 specifies Monday;
   2 specifies Tuesday;
   3 specifies Wednesday;
   4 specifies Thursday;
   5 specifies Friday;
   6 specifies Saturday.
   Note that WeekDay(0) = 4, corresponding to Thursday, 01 January, 1970.

where as the PS version is reliant on the types to give you the answer:

day :: Date -> Day
day (Date _ _ d) = d

A lot of the functions in the spec rely on milliseconds as the foundation, so I've not managed to create a correlation between the existing library and the specs and thus not been able to create valid tests.

Am I looking at this all wrong?

edit: think I am, as I'm trying to do a 1 to 1 match, when PS is doing a type representation and leaning to FFI on some parts but the specs are just the computations that are happening under the hood in JS

edit edit:

in purescript-datetime there is the use of date.setUTCFullYear(y); here and the spec representation is here. That being said we’re never going to be able to get rid of all FFI in purescript-datetime because somewhere one needs to FFI and use var date = new Date(Date.UTC(y, m, d)); to generate a date, and we simply can’t do that from within PS it self with no FFI.

[garyb]

I think converting to a Number-based representation is fine - the constructors are all private just now as it is, as they preserve invariants to stop nonsensical dates like 2020-02-31. I'd say ideally we preserve the type signatures for exported functions in the library, but everything else is fair game.

[JordanMartinez]

This might be a breaking change depending on how its implemented.

[garyb]

It could be breaking in a good way, we might be able to remove some of the annoying need to construct-via-Enum that exists for some things just now because the range of allowable is strangely constrained (it's larger than anyone would probably need, but not fully int-sized).