search

jagrosh / GiveawayBot

🎉 Hold giveaways quickly and easily on your Discord server!
https://giveawaybot.party
Apache License 2.0
649 stars 304 forks source link

[Feature Request] Ability to declare an enddate #112

Open robinduerhager opened 2 years ago

robinduerhager commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

reposting from <#585692140651151366> image

JetCrooked commented 2 years ago

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

Sanduhr32 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.