Implement the Date standard library

[LiaoPeng]

Implement the date standard library

Finished:

• [x] getFullYear, getMonth, getDate, getDay, getHours, getMinutes, getSeconds, getMilliseconds
• [x] setFullYear, setMonth, setDate, setHours, setMinutes, setSeconds, setMilliseconds
• [x] get UTC timestamp
• [x] enhancement the effective
• [x] getTimezoneOffset

[dcodeIO]

One thing I am not sure of is that each Date instance has a new reference to BaseCalendar. Is this actually necessary? Looks like BaseCalendar could also be implemented in a more global/functional style so it doesn't have to allocate that much.

[LiaoPeng]

It's not necessary. I would remove the BaseCalendar.

[LiaoPeng]

I have a question how to get the local TimeZone. It blocked me.

[LiaoPeng]

@MaxGraey The method getTimezoneOffset Return the timezone difference between UTC and Local Time. Both Date.utc and Date.now return the UTC time. I am not sure that's ok.

[dcodeIO]

It's a shame that I haven't reviewed this more thoroughly. Looking at it again I think that this went stale in my head because it needs so many managed objects to represent a single date, and a more C-like implementation with data living on the date objects felt more efficient. In general I think that this is a good approach as it passes all the tests, so wondering if you are still interested in continuing on this PR?

[LiaoPeng]

@dcodeIO I'm very interested in this PR. The implementation of the date library referred the implementation of java date. If you think a more C-like implementation are more efficient. I would try it.

[dcodeIO]

That would be fantastic, yeah. To elaborate a bit on the C-likeness, there currently are instances of CalendarDate and TimeZone required to represent a Date, so there's quite a bit of managed objects to reference count and collect. Ideally I think that having a std/util/calendar.ts exposing plain functions to work with let's say i64 values representing these would be more in-line with other stdlib internals, so that we have just a single allocation per Date instance to keep track of. Do you think it'd be possible to transform the existing code into this direction?

[MaxGraey]

Also it will be ideal if you organize the code in such a way that it could be reused for Temporal proposal (https://github.com/tc39/proposal-temporal/tree/main/polyfill/lib) in future

[dcodeIO]

Oh, wasn't aware of this one. Interesting.

[torch2424]

@LiaoPeng Ah! Thank you very much for opening this! :smile: This is a ton of awesome work, it is super appreciated! :smile:

While you work with @dcodeIO and @MaxGraey on building this out as a c-style API, and if you think it would take a while. I'd be interested in pulling this Date implementation into it's own library that could be npm install'd? I know it's not the most optimal for performance currently, but I think it'd be useful to a few folks in the communitty in the meantime :smile:

That is of course, if you wouldn't mind me doing so (giving this PR and you full credit @LiaoPeng ) ? Or we could start it together? Whichever works!

Thanks y'all! :smile:

[LiaoPeng]

@torch2424 Hey，it would take a while. Your advice is good, just do it. Now I push new commit rebased the current master branch.

[torch2424]

@LiaoPeng Ah! Thank you for rebasing! :smile: :pray:

Your advice is good, just do it.

So just to confirm, you're okay with me using the code in the PR on a torch2424/as-date repo? (Pointing back to you and this PR of course) :smile:

[LiaoPeng]

@torch2424 I am okey,

[dcodeIO]

Various Date functions have been implemented meanwhile, avoiding intermediary allocations.