Une simple vérification de la date et voilà.

Php quantique non, juste dire à l'user que le code n'est pas encore valable... CTLP.

Pareil que qwerty : tu checkes la date du serveur et basta.

Comment utiliser le mot quantique sans avoir aucune idée de sa signification... Problem exists between le cerveau et la soi-disant connaissance étalée sur la tartine.

"Grave" non, faut pas pousser.

Mais par contre avoir un code actif mais pas actif (puisque pas utilisable), me semble que ça rentre dans la même case que le chat de Schrödinger. Non ? Dans tous les cas, drôle de demande.

Si je serait pas intelligent, je demanderait pas un code actif mais non utilisaBe.

Le code peut très bien exister dans la base de donnée, sans qu'il ne sois utilisable. Il suffit de vérifier la date à la validation du code, si il est plus tôt que la date de valadité, on refuse, sinon applique la réduction.

Ou alors jusqu'à ce que le code soit actif, il offre 0 % de réduction...

Il se peut que le client veuille faire une offre promotionnelle à partir d'une date donnée et en faire la pub avant (en distribuant déjà le code).
Il faut donc que les clients qui saisissent le code avant le début de la promotion aient un message d'erreur adapté, genre "Cette offre promotionnelle ne sera ouverte qu'à partir du xx/xx/xxxx", au lieu d'avoir un message disant que le code n'existe pas (ce qui ferait croire à un bug ou que la promotion est bidon), ou de se voir appliquer à tord la réduction.

Donc oui, un code promotionnel peut très bien être "actif mais non utilisable". Ça correspond à un cas fonctionnel réel.

Ou une option activable ou désactivable à la main dans le backoffice "offrir une réduc de 10%".
Ca peut même à peu de frais être modifié pour que le % soit rentré à la main, permettant à l'avenir au client de faire les promos qu'il veut, du quota qu'il veut, quand il veut, pour la durée qu'il veut.

Sinon on fait une petite vérification sur la date qui affiche ou non le formulaire. Pas si bête puisqu'en plus ce bout de code serait facilement modifiable et a d'autres types de promo limitées dans le temps par exemple :)

Ce n'est pas une bonne idée.
Il y a une différence entre offrir 0% et ne pas offrir de réduction,.
Le site indiquera au client final que sa réduction a été pris en compte mais le prix n'a pas changé.
Généralement, la remise de réduction est consigné et pour l'administrateur du B-O, il risque d'y avoir des confusions.

Le plus gênant je pense est le terme "actif", on lui demande d'être actif mais pas actif...
Oui, la solution est de mettre une date de début (et une de fin en général) mais ça n'empêche pas l'abus de langage.

Que le client n'emploie pas les bons termes pour expliquer ce qu'il veut, c'est un classique, et une réalité de tous les jours, à laquelle le développeur doit s'adapter.
Il faut bien sur s'assurer avec le client que ce qu'il veut correspond bien à ce que vous avez compris.
Ici, prévoir une date de début et une date de fin pour la réduction, parait tout à fait logique et devrait correspondre à ce que le client veut.

Je vois pas le soucis en réalité. Même mal exprimée la demande est assez claire.

Si je devais faire un tel système, dans une table qui stocke les offres promotionnelles je mettrais certainement des dates de validité début/fin. On pourrait aussi imagine un système plus compliqué de conditions sur la date, le montant total des achats, la présence ou non d'un certain nombre d'articles,... je ne vois pas où est le souci là-dedans. J'imagine que si le client veut une promo qui commence (ou se termine) un dimanche, tu ne vas pas déployer de code ou ajouter un record à la DB ce jour-là non plus... bref, CTLP