From part 1 introducing Cypher dates and formats to part 4 where we combined duration functions and temporal components to translate amounts in one unit to another unit, we have covered a lot of ground in this series! Filling in the gaps, part 2 showed us how to truncate dates for searches and use durations for adding/subtracting amounts of time, and part 3 gave us an intro to temporal components and translations within component groups.

Photo credit *Updated Dec 15, 2021 My previous part 1, part 2, and part 3 posts on this topic introduced Cypher dates, translated formats to the Cypher-supported ISO 8601 format, calculated durations, accessed components, and translated durations to certain values. If you read those, then this post is the next post showing how to convert durations across component categories. If you haven’t read the previous posts leading up to this one, feel free to catch up (recommend at least Part 3 as this post’s prequel) - though it isn’t required.

*Updated Dec 9, 2021 My previous part 1 and part 2 posts on this topic introduced Cypher dates, translated formats to the Cypher-supported ISO 8601 format, calculated durations, and measured lengths of time. If you read those, then this post is the next step with Cypher dates on date components, component translations, and duration conversions. If you haven’t read parts 1 or 2, feel free to catch up - though this post doesn’t require the previous ones.

*Updated Dec 9, 2021 My previous part 1 post on this topic introduced Cypher dates and translated a few other date formats to the Cypher-supported ISO 8601 format. If you read that, then this post is the next step with Cypher dates that covers durations and more. If you haven’t seen part 1, feel free to catch up - though this part 2 doesn’t necessarily require reading part 1. :)

No matter what database, programming language, or webpage you might be using, dates always seem to cause headaches. Different date formats require calculations between application date pickers in user-friendly formats and system dates in backend devices and data sources. Then, programming languages each have their own libraries and structures for dealing with dates, too. This concept in the Neo4j ecosystem isn’t any less complex with Cypher (a graph query language) date formats, the APOC library date functions/procedures, and countless possible integration tools/APIs for data import and export.

I was recently working on one of our developer guides (the CSV import guide) and came across some Cypher I needed to fine-tune in the CASE statement on that page. I had some trouble finding the correct syntax, so I reached out to some Cypher experts to get some help. As it turns out, I was looking at the Cypher CASE statement the wrong way and misunderstood its structure and design.

Why is it that some query syntax seems to run faster than another when there is very little difference between the statements? Sometimes, queries will invoke what is called the eager operator in order to maintain consistent operations and avoid conflicting data changes. It still leaves the question, though, of what does this eager operation do differently and why would it be important enough to specifically avoid in certain situations?