-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Comments
An external package may not even be needed here. We could implement something based off the native |
@danielbate could you pop my name on this one for me please🥇 |
@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 😃 |
@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 |
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 |
I have removed the GraphQL resolver functionality due to functionality not possible #1572 |
We need to investigate and integrate a suitable date wrapper for broad use within the SDK.
Two critical factors must be considered:
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.)
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
The text was updated successfully, but these errors were encountered: