-
Notifications
You must be signed in to change notification settings - Fork 312
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
Comments
Accumulating options (for example, using 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 |
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. |
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? |
|
I am Confused |
You contradict yourself. The users timezone matters, because it may not be equal to bot/host/UTC.
If timezones were implemented, they would internally always be converted to the bots host timezone (UTC in the best case)
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. 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 is all related to creating a giveaway, so for example, the user wants to be able to input the end of the giveaway as: The three ways I could see this being user-friendly are:
|
Just for further clarification, in line with the original post, the request is essentially the ability to do:
|
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.
This is a dirty workaround for 1. imo and not worth going for.
Considering the average gb user this isn't an option either, please forgive the harsh categorization. |
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 |
You could use PHP normalized timezones as well - |
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. |
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.
The text was updated successfully, but these errors were encountered: