私のプロジェクトで誰かがメンバーシップを1か月購入した場合、その「月」はどれくらいの長さである必要がありますか?
年の月に関係なく、常に30日(例:2016年2月23日=> 2016年3月25日)
翌月の同じ日数(例:10/5/2016 => 10/6/2016)
または別ですか?
これは非常に簡単です。ユーザーが月の5日に請求された場合、翌月の5日に請求されます。ほとんどのユーザーは予測して計画を立てており、毎月5日ごとにサービス料金が請求されることを知っています。そうでなければ、何が起こるかを見てください
January 5
February 4
March 5
April 4
May 4
June 3
July 3
August 2
September 1
October 1
**October 31** (2 charges on the same month!!!!??????)
November 30
**December 30 = 1 year**
ご覧のとおり、ユーザーは毎月5日目に支払いを行っていました。 10か月後、彼はその月に到達していなかったとしても、最後に支払います。 12月の終わりまでに、彼は1年の支払いをしましたが、1年が1月5日であったとしてもです。
これは大したことではないかもしれませんが、一部の人にとってはそうです。あなたは顧客を利用しようとする、または貪欲で安っぽいので、EVERYBODY ELSEが行うことはできません(混乱を招くだけでなく)。
簡単に言えば: 99.99999999999999%の人がやっているなら...間違いない
編集:日付を一貫させる別の一般的な代替方法:月の残りの比例料金を請求し、月の初めに全額の請求を開始します。このようにして、ユーザーは日付が月の最初の日であることを常に知ることができ、企業の経理業務は少なくなります。
この代替手段の代替手段は、ユーザーが選択できる日付(または日付範囲)をいくつか持つことです。これは銀行や金融機関では非常に一般的であり、クライアントは月初にすべての請求を行う必要はありません。
しかし、これらの選択肢の中にさえ、共通の要因があります:日付は常に同じ月にとどまります
これを考え直す必要はありません。規制上の制約がない限り、それはあなたが望むものにすることができ、ユーザーはそれを企業ポリシーとして採用します。 (ところで、他の分野での月の定義に関連する既存の企業ポリシーはありますか?ある場合、それらの決定を活用してください。)
徹底的に時間とリソースを確保したい場合は、競合他社の動向をグラフ化できます。ユーザーに対してテストを実行することもできます。 1つを選んで、表現に一貫性を持たせます。たとえば、「XYZ Corporationで30日間のメンバーシップをお楽しみください」
Dr。Math によると、平均月には30.42日あるので、30に切り捨てても「安全」になります。:-)それはさておき、30日は公平で直感的な数値のように見えます多くの人々にとって。実用的な観点から見ると、プログラマーにとっても扱いが簡単です。もちろん、データをデータストアに挿入する人は誰でも、信頼できるカレンダーライブラリを使用してうるう年と月ごとの1日の差を考慮に入れるのが賢明です。