Re: simple calculation frustrations
Matthew wrote: >But! Then the time changed and now the calculations are off by 1 hour. Not at all! The calculations will continue to give you precise one-week intervals. It's just that with the change in timezone offset these intervals are no longer *described* using the same time of day. OK, so you want the other behaviour. I suggest that instead of storing an actual timestamp you should store a broken-down time: week number, day of week, local time of day, and (most important) timezone rule. You can put those together in DateTime to find out what point in time they refer to. Increment the week number as required. Watch out for times of day that get repeated or skipped at offset changes. These are different times of day in different timezones. -zefram
Re: simple calculation frustrations
Ahh. And we have customers all over the world. Dang. See, all of this programming was done back shortly after we "sprang forward" so we didn't think about it. Any suggestions on how I should store a customers timezone in database? Thanks, Matthew Dave Rolsky wrote: On Thu, 2 Nov 2006, Matthew wrote: I tried to do so. The problem is that the date's are stored in the users local timezone and we only store the offset from GMT. (ex: -6 or 7) Well, there's your problem right there. You realy can't do this and expect it to work, as you're finding out. You need to store the user's timezone, not their current offset. If you know all your users are in the US you might be able to come up with some hacks to deal with DST, but otherwise you really need to let DT::TimeZone do this for you (or MySQL, or something). Is there some array or table I can use to convert '-6' to something DateTime:: can use? No, there's no way to go from offset to time zone. Again, if your users are all in the US, _and_ no one's in a "weird" zone (like Indiana, parts of Arizona, etc) then you can probably convert it back. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: simple calculation frustrations
Matthew wrote: Alternately, use DateTime: I tried to do so. The problem is that the date's are stored in the users local timezone and we only store the offset from GMT. (ex: -6 or 7) Is there some array or table I can use to convert '-6' to something DateTime:: can use? Epochs are UTC on most systems, so you're probably storing them as UTC .. -6 is meaningless and so useless for DST calculations. Last week Melbourne, Sydney and Brisbane were all +1000. Now Melbourne and Sydney are +1100, but Brisbane is still +1000. And Hobart switched from +1000 to +1100 a few weeks earlier. Unless you have more information that '-6' then you'll never be able to properly convert across a DST change. You could, of course, continue to use the UTC time zone. But you still can't properly turn that into the user's local time zone as it's no longer -6, but -7 or some such. Cheers! Rick Measham
Re: simple calculation frustrations
On Thu, 2 Nov 2006, Matthew wrote: I tried to do so. The problem is that the date's are stored in the users local timezone and we only store the offset from GMT. (ex: -6 or 7) Well, there's your problem right there. You realy can't do this and expect it to work, as you're finding out. You need to store the user's timezone, not their current offset. If you know all your users are in the US you might be able to come up with some hacks to deal with DST, but otherwise you really need to let DT::TimeZone do this for you (or MySQL, or something). Is there some array or table I can use to convert '-6' to something DateTime:: can use? No, there's no way to go from offset to time zone. Again, if your users are all in the US, _and_ no one's in a "weird" zone (like Indiana, parts of Arizona, etc) then you can probably convert it back. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: simple calculation frustrations
Hi Rick, Thanks for the reply. > Best bet: Get mysql to add the week, providing it's time zone is set correctly .. I would use MySQL, but if this is the 7th iteration of an event, that's 7 mysql queries to run. (while(origDateofEvent < today)) Alternately, use DateTime: I tried to do so. The problem is that the date's are stored in the users local timezone and we only store the offset from GMT. (ex: -6 or 7) Is there some array or table I can use to convert '-6' to something DateTime:: can use? Thanks, Matthew
Re: simple calculation frustrations
Matthew wrote: hey guys, I can't believe I'm having this much trouble doing this. I'm pulling a UNIX_TIMESTAMP from MySQL and all I want to do is add a certain interval to that date then spit out the new date. Right now we only support weekly intervals in our app. Best bet: Get mysql to add the week, providing it's time zone is set correctly .. SELECT UNIX_TIMESTAMP( FROM_UNIXTIME( theField ) + INTERVAL 7 DAY ) (You're supposed to be able to do 1 WEEK too, but I can't get that to work in 4.1) Alternately, use DateTime: use DateTime; my $dt = DateTime->from_epoch( epoch => $eventDate, # So that DST is accounted for: time_zone => 'Australia/Melbourne', ); $dt->add( weeks => 1 ); $dt->epoch == (1 week after the $eventDate expressed as an epoch) Cheers! Rick Measham
simple calculation frustrations
hey guys,
I can't believe I'm having this much trouble doing this. I'm pulling
a UNIX_TIMESTAMP from MySQL and all I want to do is add a certain
interval to that date then spit out the new date. Right now we only
support weekly intervals in our app.
My original code did this fine:
eventDate = date_from_db();
while(eventDate < today) {
eventDate += (7 * 86400);
}
print eventDate;
But! Then the time changed and now the calculations are off by 1 hour.
What, in perl, can I use to accomplish this? Later on we'd like to
support bi-weekly, daily and monthly intervals.
This was so easy to do in php:
eventDate = strtotime("+1 week", eventDateFromDB);
Thanks in advance for any help.
-Matthew
