{"id":32497,"date":"2021-05-18T15:31:06","date_gmt":"2021-05-18T19:31:06","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=32497"},"modified":"2021-05-18T15:31:06","modified_gmt":"2021-05-18T19:31:06","slug":"parsing-dates-without-times","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/05\/18\/parsing-dates-without-times\/","title":{"rendered":"Parsing Dates Without Times"},"content":{"rendered":"

Quinn the Eskimo<\/a>:<\/p>\n

Parsing fixed-format date strings is tricky. For an explanation as to why, see QA1480 NSDateFormatter and Internet Dates<\/a>. However, there’s an extra gotcha when you try to parse fixed-format date strings that don’t include a time.<\/p>

[…]<\/p>

This is failing because, internally, the date formatter maps the date string to a set of date components (DateComponents<\/code>). The year, month, and day come from the date string, but the hour, minute, and second default to 0. In Brazil, daylight saving time starts at midnight, and thus the date components year: 2018, month: 11, day: 4, hour: 0, minute: 0, second: 0<\/code> don’t exist in the São Paulo time zone. When the date formatter runs these components through the calendar, it returns nil<\/code>.<\/p>

[…]<\/p>

The solution here is to set the defaultDate<\/code> property on the date formatter to something in the middle of the day.<\/p><\/blockquote>\n

It’s not documented exactly what this does, but I presume that missing date components get taken from the defaultDate<\/code>. This still makes me a bit nervous, though, because what if I have an unlucky default date whose time produces a date that doesn’t exist in that time zone? Apparently<\/a>, the isLenient<\/code> property can help with that.<\/p>\n\n

See also: The Wisdom of Quinn<\/a>.<\/p>\n\n

Previously:<\/p>\n