mirror of
https://github.com/JohnEstropia/CoreStore.git
synced 2026-01-14 07:33:28 +01:00
SectionBy Date - not string? #158
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @akac on GitHub (Aug 15, 2017).
I am doing a sectionBy Date (they are stored as the beginning of day for that data type) - in the SectionBy clause, can I get the actual date instead of a string?
I should add - I've already changed my implementation to use a date interval instead as I thought about it a bit more and realized that using a Date like that would be problematic in different timezones - but for future if I wanted to use another value like an Int or something like a Bool - beyond having to parse a string and turn it into the value, is there a way to get SectionBy to be something other than a string?
@JohnEstropia commented on GitHub (Aug 16, 2017):
The way CoreData interfaces sections is through
Strings, I'm guessing because it's designed only to display section headers. One good way is to useDateFormatterto encode the section name, then use the same formatter to decode back toDate.@akac commented on GitHub (Aug 17, 2017):
The problem with using date formatter for that is quite processor intensive. I did essentially above by using a day interval instead and parsing it from a string to a number. Works fine.
@JohnEstropia commented on GitHub (Aug 17, 2017):
Thats a matter of caching the
DateFormatterinstance. But as long as it works for your use case it should be fine.Just be careful that the sorting of intervals don't break your section ordering:
(numbers with fewer digits vs. longer ones)
e.g.
"9"will be greater than"11"alphabetically@akac commented on GitHub (Aug 17, 2017):
I've been working with dates on iOS for 8 years - my performance tests are that DateFormatter parsing is still extremely slow, so I'd really like to not depend on that.
Good point on the intervals. Shouldn't be an issue realistically as we're talking about day intervals since 2000.
@JohnEstropia commented on GitHub (Aug 23, 2017):
@akac I'll close this issue. Feel free to comment if there's anything else. Thanks!