-
Notifications
You must be signed in to change notification settings - Fork 248
Remove interface IDateTime and replace any use with CalDateTime
#705
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
a85dd77 to
a09dcf2
Compare
| /// </remarks> | ||
| /// </summary> | ||
| public sealed class CalDateTime : EncodableDataType, IComparable<CalDateTime>, IFormattable | ||
| public sealed class CalDateTime : IComparable<CalDateTime>, IFormattable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... or even struct? (not in this PR probably)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, struct would certainly be good. But we'd have to deal with all the nullability stuff first, which is not perfectly straight forward. Next step could then be to do all that also for Period, PeriodList and maybe others.
Ical.Net/Utility/DateUtil.cs
Outdated
| internal static class DateUtil | ||
| { | ||
| public static DateTime GetSimpleDateTimeData(IDateTime dt) | ||
| public static DateTime GetSimpleDateTimeData(CalDateTime dt) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we remove this method? Using dt.Value is shorter and more clear
1679c9f to
0d1cd25
Compare
|
|
This is PR is still in progress, right? Just asking because I'm assigned to review. |
|
Yes, it is still work in progress. I'm not quiet convinced, this is the right approach. Will try to comment more this weekend. |
|
@axunonb I apologize for the delay, don't find sufficient time recently. I continued the discussion in #606 (reply in thread), as this is not really specific to this PR. Please let me know what you think! |
|
Based on the discussion in #705 (comment) we decided to proceed, so the PR should be ready for review. |
|
|
|
|
||
| /// <summary> | ||
| /// Tests bug #2938007 - involving the HasTime property in IDateTime values. | ||
| /// Tests bug #2938007 - involving the HasTime property in CalDateTime values. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary could be removed?
| /// </note> | ||
| /// </summary> | ||
| public virtual IDateTime? DtEnd | ||
| public virtual CalDateTime? DtEnd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we now remove the aliases End => DtEnd and Start => DtStart and just use the more intuitive End and Start everywhere?
(The underlying Properties could stay unchanged)
| IList<Attendee> Attendees { get; set; } | ||
| IList<string> Comments { get; set; } | ||
| IDateTime DtStamp { get; set; } | ||
| CalDateTime DtStamp { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or just Stamp?
| /// Gets the timezone name this time is in, if it references a timezone. | ||
| /// </summary> | ||
| /// <remarks>This is an alias for <see cref="TzId"/></remarks> | ||
| public string? TimeZoneName => TzId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove the alias?
|
|
||
| internal static class DateUtil | ||
| { | ||
| public static DateTime GetSimpleDateTimeData(IDateTime dt) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
| } | ||
|
|
||
| public virtual IDateTime DtStart | ||
| public virtual CalDateTime DtStart |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are many of these aliases, so maybe rather address remove the the Dt... properties in a separate PR
axunonb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice. See few minor comments.



The changes in this PR are in based on the discussion in #705 (comment), where we discussed whether arithmetics and timezone-related operations on should be moved out of
CalDateTimein favor of a more flexible approach where we could even configure different timezone databases in a future iteration. We decided against it for reasons of available resources, so arithmetics are kept as part ofCalDateTime. Based on that the PR implements several improvements, most notably:IDateTimein favor of usingCalDateTimedirectly.CalDateTime, i.e. stop it inheriting fromEncodableDataTypeCalDateTime.AssociatedObject