Open Abastro opened 8 years ago
That would mean that a calendar would have to be able to talk to the datetime as the calendar has to be able to calculate the date. From ticks since the beginning. Which relate to seconds -> minutes -> hours -> days -> months -> years
Sorry, I didnt understand what you mean on this part: 'seconds -> minutes -> ...'
A day consists of ticks. Ticks create seconds, which create minutes, which create hours, which create days, months, years.
So why hours and minutes(or seconds) are important?
I have an opposite problem -- separating calendar to daytime calculations would bring yet another level of complexity.
Im not talking about daytime calculation. This issue is related with hour/minute and year/month/day.
That's the problem - you'd have to register the hour/minute/second calculator to the year/month/day logic. I still see no reason for doing so.
Why should i register them?
Because if I separate them, how would the ICalendarProvider know what IDayProvider to use?
Why ICalendarProvider should know that? One can combine them to use the system.
OK, the other way around -- the IDayProvider has to be able to change days
Correct me if I'm wrong, Abastro… but you want your mod to be able to control the YearLength (# of days)…
… and let the CAPI config (or other mods) set the Seconds/Minutes/Hours Length…
correct?
What is dayprovider? I didnt say something like that, what i want is just separate hour and minute. And setting time should be operated by central system, not a provider.
@Pitchbright yes, one difference is this: also i want to set day length.
IDayProvider would be the separate hour/minute/seconds API.
If you want to set day length then you need to control the hours, minutes and seconds anyway..?
Why? Hour, minute and second length is totally unrelated with day length.
I think hour and minute is not necessarily part of calendar, and it is complicating ICalendarProvider. So what about making it separate, and let other provider deal with it?