Skip to content
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

Add new Date Wrapper #1573

Closed
Torres-ssf opened this issue Dec 20, 2023 · 7 comments · Fixed by #1627
Closed

Add new Date Wrapper #1573

Torres-ssf opened this issue Dec 20, 2023 · 7 comments · Fixed by #1627
Assignees
Labels
feat Issue is a feature

Comments

@Torres-ssf
Copy link
Contributor

Torres-ssf commented Dec 20, 2023

We need to investigate and integrate a suitable date wrapper for broad use within the SDK.

Two critical factors must be considered:

  1. SDK Compatibility and GraphQL Resolver Integration: The date package must fully meet the needs of the SDK, and also for GraphQL resolvers. This is crucial because, during the implementation of these resolvers, specific date conversions are expected. (Refer to related issues 1572 and 1570 for more context.)

  2. Package Tree Shaking: It's essential to consider the tree-shakability of the package. This consideration is to ensure that the SDK's overall size isn't unnecessarily increased, maintaining its performance and efficiency.

Note

@Torres-ssf Torres-ssf added the feat Issue is a feature label Dec 20, 2023
@arboleya arboleya changed the title Investigating and Integrating a Suitable Date Wrapper for the SDK Add new Date Wrapper Dec 20, 2023
@danielbate
Copy link
Contributor

An external package may not even be needed here. We could implement something based off the native Date object, wrap our own functionality such as fromTai64ToUnix and document how it can be used with other packages?

@petertonysmith94
Copy link
Contributor

@danielbate could you pop my name on this one for me please🥇

@petertonysmith94
Copy link
Contributor

@danielbate Do you think the internal date for the Date wrapper, should be stored as Tai64?

I assume that Tai64 is more integral internally and that the UNIX time is generally for the end users - but my assumptions have be wrong before 😃

@danielbate
Copy link
Contributor

@FuelLabs/frontend may be able to weigh in here as to what the better internal store format should be? I'd probably recommend UNIX due to it's flexibility unless said otherwise.

@arboleya arboleya modified the milestones: 2 - Beetle, 1 - Salamander Jan 12, 2024
@LuizAsFight
Copy link
Contributor

@FuelLabs/frontend may be able to weigh in here as to what the better internal store format should be? I'd probably recommend UNIX due to it's flexibility unless said otherwise.

yes UNIX is great

@petertonysmith94
Copy link
Contributor

petertonysmith94 commented Jan 23, 2024

Got a PR here.

Just was looking for a review of the API


The following instantiation methods are available:

const tai64: DateTime = DateTime.fromTai64('4611686020108779312');
const unixSeconds: DateTime = DateTime.fromUnixSeconds(1681391398);
const unixMilliseconds: DateTime = DateTime.fromUnixMilliseconds(1681391398000);

Note: actively removed instantiation via the constructor (to avoid confusions between timestamps).


Provided are the following methods of conversion and fully date compatible:

const date: DateTime = DateTime.fromTai64('4611686020108779312');
date.toTai64() // (string) '4611686020108779312'
date.toUnixMilliseconds() // (number) 1681391398000
date.toUnixSeconds() // (number) 1681391398

@arboleya arboleya modified the milestones: 2 - Beetle, 3 - Wasp Jan 31, 2024
@petertonysmith94
Copy link
Contributor

I have removed the GraphQL resolver functionality due to functionality not possible #1572

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat Issue is a feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants