How to save datetimes for future events

Re:How to save datetimes for future events by curun1r on Monday March 23, 2015 @04:21PM (#9253140)

That's one way to handle it, but it still doesn't perform nearly as well simple greater/less/between where clauses, especially when you hit really large tables where you're going to want to index date values.

Since it's a fairly easy fix to update the way you do timezone conversions, it seems easier to put the logic there, where unit testing is easy, rather than in temp tables, stored procedures and query logic where testing is difficult and you've got state that needs to be carefully managed.

[ Parent | on HN ]

Re:How to save datetimes for future events by protomyth on Monday March 23, 2015 @04:58PM (#9253317)

"but it still doesn't perform nearly as well simple greater/less/between where clauses"

I would have to write it, but I think the performance would be fine on a large dataset.

I have found that stored procedure and queries are quite easy to unit test. Particularly in this scenario where you can build simple input data and get out specific row(s). It is actually a lot easier than testing some Classes since you need to mock up sets of objects. With stored procedures and queries you can test the code in a harness without mocking up anything.

[ Parent | on HN ]

Re:How to save datetimes for future events by edejong on Monday March 23, 2015 @07:28PM (#9253982)

I think it would be impossible to get good performance using normal (one dimensional) indices.

The problem is, when your time-zone information changes, you'd need to recalculate all your materialized views. Most popular databases lock the index/materialized view when it is being rebuild, blocking all access. When your tables are in the order of 1B rows, you can't really afford that.

[ Parent | on HN ]