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 DateTime.fromSecondsSinceEpoch and int get secondsSinceEpoch #59961

Open
KKimj opened this issue Jan 23, 2025 · 5 comments · May be fixed by #59975
Open

Add DateTime.fromSecondsSinceEpoch and int get secondsSinceEpoch #59961

KKimj opened this issue Jan 23, 2025 · 5 comments · May be fixed by #59975
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. library-core type-enhancement A request for a change that isn't a bug

Comments

@KKimj
Copy link

KKimj commented Jan 23, 2025

Proposal to Add Features to the DateTime Class

  • DateTime.fromSecondsSinceEpoch:
    A constructor that creates a DateTime instance from seconds since the epoch.

  • int get secondsSinceEpoch:
    A getter that retrieves the number of seconds since the epoch from a DateTime instance.

Using dateTime.millisecondsSinceEpoch ~/ 1000 for conversions is often verbose.

Adding these features would simplify the code and enhance the dev-experience.

It would be useful when only seconds are needed from DateTime, ultimately reducing overhead from unnecessary operations with milliseconds.

AS-IS

final DateTime now = DateTime.now(); 
// Verbose, often takes up 2 lines due to 80-column formatting.
final int seconds = now.millisecondsSinceEpoch ~/ 1000; 

TO-BE

final DateTime now = DateTime.now();
final int seconds = now.secondsSinceEpoch;

Thanks!
I’d love to hear your thoughts—feel free to drop a comment!

@dart-github-bot
Copy link
Collaborator

Summary: User proposes adding DateTime.fromSecondsSinceEpoch constructor and secondsSinceEpoch getter to simplify working with seconds since the epoch, avoiding verbose millisecond calculations.

@dart-github-bot dart-github-bot added area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. triage-automation See https://github.com/dart-lang/ecosystem/tree/main/pkgs/sdk_triage_bot. type-enhancement A request for a change that isn't a bug labels Jan 23, 2025
@lrhn
Copy link
Member

lrhn commented Jan 24, 2025

Adding constructors should be non-breaking, but adding a getter to an interface is breaking.

I don't think the benefit would be worth that.
(Which is why we need interface default methods.)

@julemand101
Copy link
Contributor

but adding a getter to an interface is breaking.

I guess it could be argued that this field could be added using extension like done with:
https://api.dart.dev/dart-core/DateTimeCopyWith.html

@KKimj KKimj linked a pull request Jan 24, 2025 that will close this issue
1 task
@KKimj
Copy link
Author

KKimj commented Jan 24, 2025

I created this PR to propose a concept for the secondsSinceEpoch using an extension.

I welcome your thoughts and feedback!

@lrhn
Copy link
Member

lrhn commented Jan 25, 2025

Not seeing the big need for this. It is just
* Duration.millisecondsPerSecond and ~/ Duration.millisecondsPerSecond, and you can make that shorter by just using 1000.

If we do decide to add something, why just seconds?
We can have minutesSinceEpoch, hoursSinceEpoch and daysSinceEpoch too (although the last one runs into daylight saving issues). Adding just one feels arbitrary.

Not sure I want all of them.

@mraleph mraleph removed the triage-automation See https://github.com/dart-lang/ecosystem/tree/main/pkgs/sdk_triage_bot. label Jan 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. library-core type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants