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

[Feature Request] Ability to declare an enddate #112

Open
robinduerhager opened this issue Sep 29, 2021 · 16 comments
Open

[Feature Request] Ability to declare an enddate #112

robinduerhager opened this issue Sep 29, 2021 · 16 comments

Comments

@robinduerhager
Copy link

robinduerhager commented Sep 29, 2021

Hey, i thought it would be cool to instead of just being able to declare an additive time period like 3H for 3 Hours + the current datetime for the giveaway to end, to be able to just declare the point in time in which the giveaway should end.

E.g.: in my case i know that i want a giveaway to end on the 10th October 2021 at 11 p.m., so it would be nice if i could just declare this date as the endpoint of the giveaway.

It would also help if we were able to accumulate these options: 3H 2M would then mean that the giveaway ends in 3 hours and 2 minutes.

@jagrosh
Copy link
Owner

jagrosh commented Dec 24, 2021

Accumulating options (for example, using 2h 3m instead of 123m) will likely be possible at some point in the future.

The primary problem with specific end times is timezones; there are many ways to deal with this problem, but not a lot of "good" solutions that are actually easier than just using the offset time.

@robinduerhager
Copy link
Author

Hey, a colleague and i just had a chat about timezones and we were asking ourselves if it wouldn't be possible to input an enddate to the giveaway bot which calculates the offset based on that and the current datetime the user has (based on the users timezone)?

@jagrosh
Copy link
Owner

jagrosh commented Aug 25, 2022

The bot doesn't know the user's timezone.

I believe that the Discord devs have mentioned adding a type of field for a date, which would likely be a requirement before this kind of feature was attempted.

@jagrosh
Copy link
Owner

jagrosh commented Aug 25, 2022

Also, as of the slash command rewrite, the combined time units are possible. Units like 2d 5m, 3 days 5 hrs 2 min, and 4d3h6m1s are all valid

@Dougley
Copy link
Contributor

Dougley commented Aug 25, 2022

Why would the timezone matter in this context? The user wants the giveaway to end at X in their timezone presumably, so knowing exact timezones seems irrelevant.

If you absolutely need to implement timezones, you could always require UTC for exact datetimes. It would make this feature more of a power tool but I assume this was already intended as a power tool.

@JetCrooked
Copy link
Contributor

Why would the timezone matter in this context? The user wants the giveaway to end at X in their timezone presumably, so knowing exact timezones seems irrelevant.

because if the bot receives (and by extension shows) a plain text end time then that time is wrong for anyone not in the giveaway host's timezone?

@Dougley
Copy link
Contributor

Dougley commented Aug 25, 2022

because if the bot receives (and by extension shows) a plain text end time then that time is wrong for anyone not in the giveaway host's timezone?

It doesn't have to show a plain timestamp

@JetCrooked
Copy link
Contributor

reposting from <#585692140651151366>
image

@JetCrooked
Copy link
Contributor

JetCrooked commented Aug 25, 2022

I am Confused
I think I may have misread the original feature request so imma read it again
yeah no still confused

@Sanduhr32
Copy link
Contributor

Why would the timezone matter in this context? The user wants the giveaway to end at X in their timezone presumably, so knowing exact timezones seems irrelevant.

You contradict yourself. The users timezone matters, because it may not be equal to bot/host/UTC.
However you may be able to assume a hosting users timezone with their locale.

If you absolutely need to implement timezones, you could always require UTC for exact datetimes. It would make this feature more of a power tool but I assume this was already intended as a power tool.

If timezones were implemented, they would internally always be converted to the bots host timezone (UTC in the best case)

It doesn't have to show a plain timestamp

Afaik it shows a relative and an absolute UTC unix timestamp of the endtime. The client will format it according to the users local timezone.
(You can have timezone depending unix timestamps)

The implementation will be properly done regarding timezones, if it's done. I wouldn't expect anything else because everyone knows how delicate timezones are.

I can suggest javas DateTimeFormatter using a standard or custom pattern for parsing timestamps reliably with ease.
This includes timezone information. Javas modern time api also allows you to adjust given time in a timezone to a different timezone.

@jagrosh
Copy link
Owner

jagrosh commented Aug 25, 2022

This is all related to creating a giveaway, so for example, the user wants to be able to input the end of the giveaway as: August 30th 2022 5:00 PM, or something like Tomorrow at 4pm. However, this exact time may be different for the user and for GiveawayBot, so GiveawayBot would also need to know the user's timezone. Requiring the timezone in the prompt though drastically complicates things for the average user, who may not even know the technical name for their timezone.

The three ways I could see this being user-friendly are:

  1. Discord adds a "date" type option to commands, which would bring up a calendar modal (like how the search calendar appears) which would provide a unix timestamp under the hood to the bot (which would not be ambiguous about timezone).
  2. Utilize an existing system for allowing scheduling of giveaways. For example, the ability for a Discord event to have an attached giveaway that matches the event's time.
  3. Require a timezone in addition to the human-readable date (this option is more complicated and confusing for a lot of users).

@jagrosh
Copy link
Owner

jagrosh commented Aug 25, 2022

Just for further clarification, in line with the original post, the request is essentially the ability to do:

/gstart end:10th October 2021 at 11 p.m. winners:1 prize:Something

@Sanduhr32
Copy link
Contributor

The three ways I could see this being user-friendly are:

  1. Discord adds a "date" type option to commands, which would bring up a calendar modal (like how the search calendar appears) which would provide a unix timestamp under the hood to the bot (which would not be ambiguous about timezone).

I completely agree with this one, i don't know why they have not implemented this yet. This is requested since day 0 of slash command options i believe.

  1. Utilize an existing system for allowing scheduling of giveaways. For example, the ability for a Discord event to have an attached giveaway that matches the event's time.

This is a dirty workaround for 1. imo and not worth going for.

  1. Require a timezone in addition to the human-readable date (this option is more complicated and confusing for a lot of users).

Considering the average gb user this isn't an option either, please forgive the harsh categorization.

@Dougley
Copy link
Contributor

Dougley commented Aug 25, 2022

Discord adds a "date" type option to commands, which would bring up a calendar modal

I don't know why you're suggesting to reinvent the wheel by waiting for a modal type that might not even be in development.

Like I suggested earlier, using RFC 1123 / RFC 822 and accepting /gstart end:Thu, 25 Aug 2022 20:19:59 GMT winners:1 prize:Something is a good solution to this.

@bup0441
Copy link
Contributor

bup0441 commented Aug 25, 2022

Requiring the timezone in the prompt though drastically complicates things for the average user, who may not even know the technical name for their timezone.

You could use PHP normalized timezones as well -
/gstart end:Thu, 25 Aug 2022 20:19:59 timezone:Europe/London winners:1 prize:token access
It could even be supported by autocomplete for ease of access, and if you don't want to roll it into /gstart for fear of complication, turn it into a separate command called /gschedule or something

@jagrosh
Copy link
Owner

jagrosh commented Aug 26, 2022

Personally I think requiring a very specific format is going to cause more confusion and support queries/complaints than the benefit. Also, it has been stated here that a date picker option type is in development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants