[Design document] Issue 397: Random Date/Time Only

[prasadtelkikar]

This is regarding adding a new feature to support DateOnly and TimeOnly structs to C# Bogus repository.
Before I start working on this issue, I have an approach to solve this issue. I would like to discuss it with you all.

Add new functions to the existing Date class. These functions will be just overloading the existing functions that we already exposed. The change will be only in the return type

Here is the rough design document for the above approach.

Add new functions In Date class:

Project: Bogus
Class Name: Date

Implementation:

      public DateOnly PastDateOnly(int yearsToGoBack = 1, DateOnly? refDateOnly = null)
      {
           //Convert DateOnly to DateTime
           var dateTime = refDateOnly.ToDateTime(default);
           //Call existing Past method.
           var dtTimePast = Past(yearsToGoBack, dateTime);
           //Convert back to DateOnly and return
           return DateOnly.FromDateTime(dtTimePast);
      }

The following table shows methods that will follow a similar logic to support DateOnly and TimeOnly.
I added two columns that describe the return type of that method.

If you are agreeing with this approach, then I will include all methods mentioned in the above table will raise PR soon.

Advantages of this implementation:

• Less buggy, not introducing extra complexity. This approach will be aligned to what we already implemented.

Question:

1. Should we keep the same name of functions and change just return time?
   e.g
   public DateTime Past(int yearsToGoBack = 1, DateOnly? refDateOnly = null){...} //For DateTime

    public DateOnly Past(int yearsToGoBack = 1, DateOnly? refDateOnly = null){...}  //For DateOnly
   

Another approach:

• This is my second approach, where define DateOnly and TimeOnly as new DataSets.
• Both the classes will inherit from Date Class, override the behavior of existing methods available in the Date class inside the respective derived class.

Advantages of this implementation:

• This will give space to grow DateOnly and TimeOnly functionality in the future.

Questions:

1. If we go with my second approach then what will be the class name? will it be the same "DateOnly" and "TimeOnly"? if yes, then we need to add extra code to distinguish Bogus.DateOnly and System.DateOnly. We can do this using name aliasing.

Looking forward to hearing from you.

Thanks and Regards,
Prasad

FYI @bchavez, @rgarrison12345

[prasadtelkikar]

I received a comment from @bchavez , adding to this thread.

#397 (comment)

[prasadtelkikar]

Hi @bchavez and @rgarrison12345,

I wrote code for all methods mentioned by @bchavez in his comment #397 except two. Could you please help me with some hints/input regarding the implementation of the below methods?

• SoonTimeOnly - Some time in the next 15 minutes
• RecentTimeOnly - Some time in the last 15 minutes

Thanks,
Prasad

[bchavez]

@prasadtelkikar I would follow parameter defaults and inputs similar to Soon and Recent. Is that possible?

[bchavez]

If it helps, you might want to push a draft PR so we can start taking a look at the code.

[prasadtelkikar]

Hi @bchavez,

Thanks for the suggestion, I implemented SoonTimeOnly and RecentTimeOnly functions.
I raised PR #399 for the issue #397, Kindly take a look and let me know your thoughts.

Note: As this changes required introduction of new TargetFramework i.e. .NET60. PR build is failing for the latest target framework.
I am not sure how to fix that, kindly provide way to fix the PR build. Here is the link: Bogus 1111

FYI @rgarrison12345

[bchavez]

Great. Thanks so much @prasadtelkikar. Don't worry too much about the failed build. As we noted in #397 (comment) I will need to do some work to upgrade my tooling and AppVeyor's new VS2022 image before merging your new #399 PR.

I will rebase when the tooling updates are completed. After rebase, PR #399 should build okay.