GiveawayBot
GiveawayBot copied to clipboard
[Feature Request] Ability to declare an enddate
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.
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.
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)?
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.
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
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.
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?
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?
reposting from <#585692140651151366>
I am Confused I think I may have misread the original feature request so imma read it again yeah no still confused
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.
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:
- 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).
- 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.
- Require a timezone in addition to the human-readable date (this option is more complicated and confusing for a lot of users).
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
The three ways I could see this being user-friendly are:
- 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.
- 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.
- 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.
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.
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
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.