2 ms·
I think that's a bit naive. Properly supporting calendrical calculations serves two major purposes: 1. Serve the billions of people who don't use the Gregoria
by xenadu02 8y ago
I think that's a bit naive.
Properly supporting calendrical calculations serves two major purposes:
1. Serve the billions of people who don't use the Gregorian calendar or who live in areas that don't match your idea of time zones.
2. Functions as a human form of "platform independence". Properly handling dates/times quickly exposes places you've made silly assumptions or accidentally broken things. This protects you from actual bugs and ensures you avoid whatever the future version of the Y2K problem is. Such bugs are always easier to fix when you have a smaller database and fewer users.*
* In general bugs and breaking changes _never_ get easier. Every day you delay increases the pain imposed on future you and users. Obviously there is a balance - a startup needs to worry about getting to "default alive" first and foremost - but don't delay too long and where it doesn't impose an inordinate cost do it right the first time.
- jchw 8y agoI didn't say you would Never want to support multiple calendars, but like I said. For better or worse, most software written will not.
- nitwit005 8y ago> Serve the billions of people who don't use the Gregorian calendar or who live in areas that don't match your idea of time zones. There isn't that much use of non-Gregorian calendars in software, even in places that do make use of them. And if you do support them, it's another source of bugs, as you have to deal with new Japanese era names and the like: https://blogs.msdn.microsoft.com/shawnste/2018/04/12/the-japanese-calendars-y2k-moment/ https://blogs.msdn.microsoft.com/shawnste/2018/04/12/the-jap...