[Typo3] Timezones and Dates in the Extended Calendar

[Justin Patrin]

On 10/13/05, Justin Patrin <papercrane at gmail.com> wrote:
> On 10/13/05, Justin Patrin <papercrane at gmail.com> wrote:
> > On 10/12/05, Christopher <bedlamhotel at gmail.com> wrote:
> > >  Hi,
> > >
> > > On 12/10/05, Justin Patrin <papercrane at gmail.com> wrote:
> > > > I'm using the Extended Calendar plugin and have entered some events in
> > > > the Backend. They display just fine there with the correct dates and
> > > > times. However, int he Frontend they have 7 hours added to the times.
> > > > I've tried changing the serverTimeZone setting in localconf.php to
> > > > various values and have tried installing the timezone extension and
> > > > setting that various ways. Neither of those changed anything.
> > > >
> > > > This is on FreeBSD running Apache. The TZ environment var isn't set.
> > > > date() and time() in one of my own scripts displays in GMT. I've
> > > > noticed that the start_date and end_date in the DB have 7 hours added
> > > > to the days. So if 2005-10-02 is entered as the start_date the DB has
> > > > the timestamp for 2005-10-02 07:00:00. Everything still displays fine
> > > > in the backend, though. I really have no idea how or why TYPO3 is
> > > > doing this.
> > >
> > > I don't think Typo3 _is_ doing it, although I was unable to solve the
> > > problem with putenv() either. But since extended calendar uses TS for
> > > _everything_, you can solve this problem with a bit of TS wizardry.
> > > Here's my post to the list from last August detailing how I solved
> > > this problem. Note that I only needed to do this for the starting
> > > times of events; I have no idea if this solution will work with all
> > > date operations in the extension:
> > >
> > > http://lists.netfielders.de/pipermail/typo3-english/2005-August/010263.html
> > >
> >
> > Yes, I saw that actually.
> >
> > Ugh. That seems like a horrible hack. I ended up "fixing" it by adding
> > some simple code to class.tx_calendar_pi1.php. Where it sets
> > $row['event_start'] and $row['event_end'] I added "- 7 * 60 * 60".
> > This is, of course, not a real solution, but it's much simpler than
> > mucking about in TS (especially as cimplicated as what I see in your
> > post). Not to belittle your work, but I'd rather not have that
> > complicated of a hack for something which should be so simple.
> >
>
> I take it back. It fixes one of my events but the other one is now 1
> hour off. Looks like *something* is calculating PST with daylight
> savings time, making the dates *now* correct and the dates after Oct 1
> hour off again.
>
> Could *someone* with some knowledge of the timezone system(s) that
> TYPO3 uses tell me something here? It *looks* like, somehow, for some
> reason, TYPO3 is adding a timezone offset to the *day* value in the
> database. It ends up as a timestamp which is 7 or 8 hours off of the
> day specified.
>
> Is this strtotime? (I don't think so, I don't see any problems in a
> test script). Is this a strftime problem? If TYPO3 magically picking
> up the timezone of the user's browser and offsetting things? AFAIK
> there is *no* timezone set for the server and I don't think that TYPO3
> has a timezone set up (in addition changing what values I could find
> did nothing).
>
> > Anyone else have any ideas? This either has to be TYPO3 or PHP doing
> > this and I'm pretty sure it's TYPO3. PHP certainly isn't going to take
> > a date sent via a form an change it to be 7 hours later by itself.
> >
>

Again, responding to myself, a bit more info. I checked the values
submitted by the form on the client side (which the JS sets) and and
timestamp sent back to TYPO3 (server-side) is, in fact, correct (no
extra 7 hours), so it's the server-side doing the adding.... where
should I look for this?

--
Justin Patrin