fix(date): persist all attributes passed by options

[seflue]

Store all attributes passed as option via Date:set, especially date_only.

I am raising this as a separate PR and precondition to PR #650. If we don't treat every field in the given date consequently, we get suprising behavior if some of the fields are present within the given "time" parameter. The idea of the function is, to allow adjusting an existing date instance by a subset of it's fields given as a table and returns the adjusted date as new value from the method.

This fix ensures, that every field can actually be adjusted within this function. I observed bugs while working on my time picker, if I used this function to get a Date object with adjusted time values (hours, minutes).

[kristijanhusak]

Store all attributes passed as option via Date:set, especially date_only.

Do you need this only for date_only ? I'd prefer allowing overwriting as less as possible options to avoid side effects.
If yes, let's start only with date_only and we can extend it if necessary.
I want to revisit the whole Date class since it became a bit confusing, so I want to make sure to minimize the unnecessary changes.

[seflue]

Store all attributes passed as option via Date:set, especially date_only.

Do you need this only for date_only ? I'd prefer allowing overwriting as less as possible options to avoid side effects. If yes, let's start only with date_only and we can extend it if necessary.

I think it is mainly date-only.

I want to revisit the whole Date class since it became a bit confusing, so I want to make sure to minimize the unnecessary changes.

Initially I thought, why not make everything consistently changable, because this method from_time_table actually allows to create precise copies of existing date objects and to adjust only the fields someone wants to change, which is in my eyes cleaner, than creating the copy and having to assign the values manually. Leaving some fields out of this method leads to more surprising behavior from a callers perspective and is actually more a side-effect than treating every field equally (which is plain and simple in my eyes).
The current behavior is confusing, but it doesn't prevent the programmer to actually achieve, what they want, it's just more cumbersome and needs inside knowledge of the method.

If you still insist to treat some fields differently than others, I can try to minimize the changes, but then we should at least document, which fields can be adjusted by this method and which not, and, most importantly, why they are not adjustable. Could you provide me some field-specific why-arguments, then I would include this into the documentation.

[kristijanhusak]

The current behavior is confusing, but it doesn't prevent the programmer to actually achieve, what they want, it's just more cumbersome and needs inside knowledge of the method.

Lua unfortunately does not allow (easily) to have private methods and fields. I need to revisit annotations to set what should be considered private and what is public.

If you still insist to treat some fields differently than others, I can try to minimize the changes, but then we should at least document, which fields can be adjusted by this method and which not, and, most importantly, why they are not adjustable. Could you provide me some field-specific why-arguments, then I would include this into the documentation.

I'd like to leave the things that are expected to be changeable, like what we currently have (day, month, year, hour, min, sec), and we can allow changing active and date_only.
Other things are mostly internal, and those should not be manipulated directly. Some of them are recalculated anyway in the new() method, like timestamp, dayname, but others are not. The more we directly expose, the more we need to maintain later. I don't believe a lot of people are using the Date class outside of the ordinary, but I still want to be on the safe side.

I agree that it needs to be documented. I would do that with a proper annotation on the set() method, since currently it says only table.
For now, lets just add what is necessary for your PR that adds time to the calendar, and once I revisit the whole Date class I'll add proper types and limitations where necessary.

[seflue]

I minimized the set of changeable fields to the minimum necessary for my PR.