Closed galenseilis closed 8 months ago
What would be the benefit of converting back to an ordinary datetime
object? FiscalDateTime
is already a subclass of datetime
, so any code that requires a datetime
will still work, and all attributes remain unchanged.
@adamjstewart Thank you for the quick response!
I think your questions captures a misunderstanding I have about the package. That's probably due to my inexperience with fiscalyear
. I just stumbled upon it and I'm trying to evaluate whether it will meet my requirements.
Thinking about your question prompted me to create an example.
import fiscalyear
fiscalyear.setup_fiscal_calendar(start_year='previous', start_month=4)
fd = fiscalyear.FiscalDate(2023, 4, 1)
print(fd.year, fd.fiscal_year)
This prints (2023, 2024)
.
Okay, check me on these inferences please.
fiscalyear.FiscalDate(foo, bar, baz)
it is for the calendar year foo-bar-baz
. year
attribute not the fiscal_year
is what is being printed in fiscalyear.FiscalDate.__repr__
. year
attribute really is the calendar year.If I've got this right, I can see why there is no added benefit because the object instance would be keeping the calendar year as the year
attribute anyway. 😅
Let me know if I got this right now.
Yes, this is correct. fiscalyear.FiscalDate
is a subclass of datetime.date
with extra attributes to query the fiscal calendar. The constructor is identical, and all existing attributes remain unchanged. All we do is add extra attributes. Fiscalyear as a whole is a very simple library designed to do one thing well.
[...] a very simple library designed to do one thing well.
That's my favorite type of library. 💓
Thank you for indulging in my questions and discussion as I learn.
It would be convenient to be able to convert back to an ordinary datetime object. I could have missed this, but I didn't see it in the documentation. I imported the module and took a look around and didn't see explicit support for this.
Being in Canada, the conversion is straightforward using the
FiscalYear
data structure in my own code. But I figured this would be something nice to have in the fiscalyear package itself.