4 ms·

I have a feeling that you're oversimplifying it. You will have events/dates on the table which are even for a single timezone have multiple offset like before/a

by tmd83 12y ago

I have a feeling that you're oversimplifying it. You will have events/dates on the table which are even for a single timezone have multiple offset like before/after DST. Essentially you will have to store the whole timezone rule data in some table and dynamically query based on the time value of the date, location and corresponding tz rule. I believe it would be nightmare of a query. But even that maybe possible if you have to basically do this for one single event table and few queries. Try to do this kind of query for 100s of tables and thousands of date type of column and see how quickly it spirals out of control.

protomyth 12y ago
I think your over complicating the query. You split the location -> time zone -> offset into one query to a temp table (doesn't need to run each time - very easy to predicate needed updates) then do the local time / location part. Its really not that hard. I should point out I'm in the SQL / Stored Procedure camp and not talking using some object mapping solution. That might get problematic.
- tmd83 12y ago
  Not sure I understand the temp table part. My point was that you are always calculating it dynamically. So if you have two dates in location x, timezone y and you save the rows time1, x = time1, ytimezone, yoffset time2, x = time2, ytimezone, yoffset but given the timezone rule change time1, ytimezone has an offset of z1, time2, ytimezone has z2 offset. Now you have to compare the 'time' against the validity period of each offset dynamically in the query. You can I guess get away with also storing the UTC additionally and schedule recalculate on timezone rule change. But even then the ambiguity of which timezone to actually apply remains as mentioned in other comments.
  - protomyth 12y ago
    "My point was that you are always calculating it dynamically." My point is that you aren't. Location -> Time Zone -> Offset is something that only has to be updated infrequently. The results are then stored in a temp or work table (whatever optimizes better). Now I have a table with (Location, Local Event Time) which I can do a range on the offset query to get the Local Times. I would write the schema and queries, but this depends on which database you use. I've done this on Sybase 12.5 and it worked just fine. "But even then the ambiguity of which timezone to actually apply remains as mentioned in other comments." No, I have the wanted local time at a location.
- curun1r 12y ago
  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.
  - protomyth 12y ago
    "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.
    - edejong 12y ago
      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.

by tmd83 12y ago

protomyth 12y ago

I think your over complicating the query. You split the location -> time zone -> offset into one query to a temp table (doesn't need to run each time - very easy to predicate needed updates) then do the local time / location part. Its really not that hard. I should point out I'm in the SQL / Stored Procedure camp and not talking using some object mapping solution. That might get problematic.

tmd83 12y ago
Not sure I understand the temp table part. My point was that you are always calculating it dynamically. So if you have two dates in location x, timezone y and you save the rows time1, x = time1, ytimezone, yoffset time2, x = time2, ytimezone, yoffset but given the timezone rule change time1, ytimezone has an offset of z1, time2, ytimezone has z2 offset. Now you have to compare the 'time' against the validity period of each offset dynamically in the query. You can I guess get away with also storing the UTC additionally and schedule recalculate on timezone rule change. But even then the ambiguity of which timezone to actually apply remains as mentioned in other comments.
- protomyth 12y ago
  "My point was that you are always calculating it dynamically." My point is that you aren't. Location -> Time Zone -> Offset is something that only has to be updated infrequently. The results are then stored in a temp or work table (whatever optimizes better). Now I have a table with (Location, Local Event Time) which I can do a range on the offset query to get the Local Times. I would write the schema and queries, but this depends on which database you use. I've done this on Sybase 12.5 and it worked just fine. "But even then the ambiguity of which timezone to actually apply remains as mentioned in other comments." No, I have the wanted local time at a location.
curun1r 12y ago
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.
- protomyth 12y ago
  "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.
  - edejong 12y ago
    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.