[Typo3] Timezones and Dates in the Extended Calendar

[Justin Patrin]

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.
>

--
Justin Patrin