[issue] Daylight Saving

zoeglingjulian · 2005-10-30 08:37:52

Hi,
I think I post this here because in my eyes, it’s a bug:

Perhaps it helps because of the time on the server and all that; I’m hosted at Textdrive.

I live in Germany. That means, we’ve got Daylight Saving. So, I write an article in the summer, at 10 o’clock in the morning (local time). The date gets saved in the mysql database in a GMT¹ or however its called. In the database, it says “8 o’clock in the morning” because my timezone is GMT+1 with Daylight Savings, thus I’m “two hours ahead”, so to speak.

Now, if the posttime of the article is displayed somewhere, Textpattern just takes the time in the database and adds the offset for the timezone and for the Daylight Saving and adds that to the stored time. So the displayed time is, correctly, “10 o’clock”.

Now, fast forward, it’s winter, Daylight Saving is over. Clock’s changed. I write an article, at 10 o’clock in the morning (local time) again. Now Textpattern displays “11 o’clock” as the time the article was posted, because it’s still adding that hour of Daylight Saving.

So I go to the prefs, turn off Daylight Saving. Now the time of the article’s displayed correctly, “10 o’clock”. But hey, what about the article I posted during the summer? It’s now — without me changing anything related to the article — at 9 o’clock in the morning. That’s incorrect.

What can be done about it? How about a flag in the database that marks the article as being published during Daylight Saving, or something else? Because dates change because of the current pratice, that’s not so great.

Well, this is the system I figured out, I’m not completely sure I’m right. But anyway, the time for past articles changes, and that shouln’t be the case. Or is there anything I missed?

¹ At the moment I don’t have access to phpmyadmin on my server, because I’m getting a weird error, so I’m not sure it’s saved in GMT.

Last edited by zoeglingjulian (2005-10-30 08:41:00)

zem · 2005-10-30 11:52:20

Sadly, PHP still doesn’t support time zones, at least until 5.1; and even then, it’s not clear how daylight saving time is supported, if at all.

I’ve thought about the method you suggest before. For it to work, we’d have to store an extra bit of information with every time/date that Textpattern stores, and make sure we don’t mess up the offsets – think date-based permlinks, comment dates, etc. That’s a lot of work, and a lot of potential bugs.

A less risky solution, pre-5.1, would be to use either the TZ environment variable, or the Pear Date classes (if they support daylight saving time correctl y – I can’t tell, it’s PEAR, which means it doesn’t have any bloody documentation now, does it? bah!). That could be done in one place, the safe_strftime() function, since proper TZ support knows the rules about which date ranges are and aren’t daylight savings for the selected locale.

TheUsability · 2005-10-31 05:15:49

Okay, but what about the old articles? Got the same problem. I can adjust the time to something (now) meaningful, but all the old articles’ times change too. That shouldn’t be!

zem · 2005-10-31 06:55:08

Basically: live with it, until someone comes up with a feasible solution.

TheUsability · 2005-10-31 11:12:33

Hmm, that kinda sucks the big one. I really think the time stamp should be just created ONCE, not on the fly. Old articles should be saved with the current time according to their GMT+/-x / Daylight Savings, but not purely GMT and then have the factor added to it afterwards when getting read out. That’s just wrong. What’s saved is saved, especially for time stamps. The second problem, namely knowing what the right current time is, is something else alltogether IMO. You’re very welcome to tackle that. But old time stamps just shouldn’t change. That’s just wrong, man.

_TU

zem · 2005-10-31 12:16:06

Old articles should be saved with the current time according to their GMT+/-x / Daylight Savings, but not purely GMT and then have the factor added to it afterwards when getting read out.

It’s not clear what you mean. GMT doesn’t have daylight savings time. Textpattern stores timestamps as Unix timestamps, more or less, the same as everyone else stores them. The timezone and/or daylight savings factor is applied only when they’re displayed. Are you saying we should do that, or shouldn’t?

But old time stamps just shouldn’t change. That’s just wrong, man.

They don’t change.

TheUsability · 2005-10-31 12:29:01

I think timezone and/or daylight savings factor should be applied before an article gets saved – and that should be the time stamp that goes into the db. (Or just save the timezone and/or daylight savings factor with it!) It’s silly to be able to mess with timezones after the fact (i.e. the posting).

Because times sometimes do change (I’m sounding like Mr. Zimmermann…) and that doesn’t have to mean that every old timestamp changes with it. It’s stupid that all my old articles are now an hour early because I changed into daylight savings!

They don’t change.

Thanks for clearing that up – what I meant was the time stamp that’s displayed with an article, not the time stamp that goes into the db.

_TU

Mary · 2005-10-31 15:48:03

I agree, dst should only be taken into account when publishing/saving (but not with custom date), not when rendering later.

Have Txp always generate the timestamp, instead of MySQL. Save the timestamps as GMT, but also take into account dst setting then. Then drop $is_dst from tz_offset().

<pre><code>if ($publish_now == 1)
{ $when = date(‘Y-m-d h:i:s’, gmmktime() + ($is_dst ? 3600 : 0));
}

else
{ $when = “$year-$month-$day $hour:$minute:00”;
}</code></pre>

zoeglingjulian · 2005-10-31 16:04:15

I’d go with that solution, too. That sounds simple and I can’t see any drawbacks.

TheUsability · 2005-10-31 16:15:31

hey mary,

nice to see you going at this!

I’ve got only one drawback: what about people who were too silly to use DST? Like myself, who used GMT+2 instead of GMT+1 & DST before this weekend… That’s why I thought TXP should just write whatever time is used by the poster to the db. Once saved, there should be no change anymore, no matter what other changes you make to your time prefs.

_TU

Mary · 2005-10-31 16:26:19

Re-save with a custom time. The field is pre-populated, so all you need to do is make sure the checkbox is checked for the “set time to now” (not those exact words).

zoeglingjulian · 2005-10-31 16:29:40

And maybe confirm the time settings somewhere during the installation.

Textpattern CMS

Textpattern CMS support forum

#1 2005-10-30 08:37:52

[issue] Daylight Saving

#2 2005-10-30 11:52:20

Re: [issue] Daylight Saving

#3 2005-10-31 05:15:49

Re: [issue] Daylight Saving

#4 2005-10-31 06:55:08

Re: [issue] Daylight Saving

#5 2005-10-31 11:12:33

Re: [issue] Daylight Saving

#6 2005-10-31 12:16:06

Re: [issue] Daylight Saving

#7 2005-10-31 12:29:01

Re: [issue] Daylight Saving

#8 2005-10-31 15:48:03

Re: [issue] Daylight Saving

#9 2005-10-31 16:04:15

Re: [issue] Daylight Saving

#10 2005-10-31 16:15:31

Re: [issue] Daylight Saving

#11 2005-10-31 16:26:19

Re: [issue] Daylight Saving

#12 2005-10-31 16:29:40

Re: [issue] Daylight Saving

Board footer