On Fri, 3 Nov 2006, Zefram wrote:
Dave Rolsky wrote:
Pretty much all DBMS's (ok, not SQLite) have support for datetime as a
data type.
Worms. Can thereof. A datetime type is not a primary feature of a DBMS,
so it's probably not had much attention paid to it. Until recently,
MySQL's datetim
To clarify, this is all in reference to our "event" system. A customer
can create an event for March 3, 2006 as a one time event or a weekly
recurring event.
We are storing '2006-03-03' in the database as the "base date".
In order to find the date of the next event, we take the base date from
Dave Rolsky wrote:
>Pretty much all DBMS's (ok, not SQLite) have support for datetime as a
>data type.
Worms. Can thereof. A datetime type is not a primary feature of a DBMS,
so it's probably not had much attention paid to it. Until recently,
MySQL's datetime type allowed dates such as 2006-04
On Fri, 3 Nov 2006, Zefram wrote:
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 w
Thanks for the link Philip. I downloaded and updated all my
/usr/share/zoneinfo then imported them into MySQL using their
mysql_tzinfo_to_sql tool.
Is there a better way to store the time zone of our customers other than
VARCHAR? I noticed that the utility above created an INT indexed table
Matthew wrote:
> 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?
I think the best way is probably using
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, s
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
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 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 ne
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 d
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 ad
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:
eventDat
13 matches
Mail list logo
