[issue] Daylight Saving

zem · 2005-10-31 22:51:25

$when = date('Y-m-d h:i:s', gmmktime() + ($is_dst ? 3600 : 0));

This is not correct. DST should not be applied to GMT. This gives me a post time that’s 11 hours out.

There’s one way to get times and dates right, and that’s to store them as plain vanilla GMT, then apply any time zones and DST offsets at display time.

Anyone who wants prove me wrong can submit a patch and a comprehensive set of test data, including cases like date-based URLs, time zone preference changes, and moving data from one server to another in a different time zone.

Mary · 2005-10-31 23:04:40

> “This is not correct. DST should not be applied to GMT. This gives me a post time that’s 11 hours out.”

How is that? The database stores the gmt adjusted date, you still apply timezone at display time, whether its text or url?

zem · 2005-10-31 23:23:13

How is that? The database stores the gmt adjusted date, you still apply timezone at display time, whether its text or url?

Try it on a server where your timezone is different to the server’s.

Ignoring that bug: if is_dst is true, a new post won’t show up for an hour, because of the future/past article check.

Also, it’ll fail on border cases, during the dst -> no dst transition.

Trust me: there is nothing simple about time and date calculations. I’ve been through all this before.

Last edited by zem (2005-10-31 23:25:42)

zem · 2005-10-31 23:28:22

PS: I took a look at the PEAR Date class. It has some support for DST, but relies on the server TZ environment variable, which doesn’t work on Windows, and causes threading problems on some servers. I also suspect it doesn’t handle transition times correctly.

Mary · 2005-11-01 01:51:27

Mm, I see. Oh I do ‘trust’ you, you’ve got a heck of a lot more programming experience than I do wasn’t saying it was easy (I’m also not saying any switch should happen just ‘likethat’, either), just speaking it while working it through my brain, ‘cuz I may as well learn at the same time. :)

Damn Benjamin Franklin.

zem · 2005-11-01 04:14:23

I am investigating some other options for dealing with this. No promises though.

TheUsability · 2005-11-01 18:18:05

Well, to get it all straigt: It would be nice if articles that have been saved already wouldn’t change their time when there is timezone / daylight savings changes. The change should only apply to new articles, not the old ones. That’s all I’m saying. If I change into daylight savings, my old articles shouldn’t change with it. Period.

Besides that, TXP should have a method to get times straight itself. But having it not switching time around on old articles at all would be a great step already, since users tend to be able to change the time when they have to. What they can’t do is to change the time of every single old article. That’s just silly.

Thanks,
_TU

Last edited by TheUsability (2005-11-01 18:18:47)

zem · 2005-11-01 21:09:16

Just to clarify: the times stored in old articles don’t change. The DST offset is added on-the-fly when the time is displayed. No data is lost or modified.

TheUsability · 2005-11-01 23:03:00

It seems to me that also the GMT+/-x offset is added on the fly, zem, not only the DST offset.

Secondly, can that offset adding be stripped in some way for old articles? (problem is, though, old articles will appear in just GMT then, right?!)

Last edited by TheUsability (2005-11-01 23:03:56)

zem · 2005-11-01 23:31:46

It seems to me that also the GMT+/-x offset is added on the fly, zem, not only the DST offset.

Correct.

Secondly, can that offset adding be stripped in some way for old articles? (problem is, though, old articles will appear in just GMT then, right?!)

Also correct. If you really want absolute control over the time and date displayed for your articles, turn off DST and set the time to whatever you want with the “publish at” function.

Elenita · 2005-11-02 19:21:00

Honestly, all this code talk is way over my head. But one thing I think people working on this should keep in mind is that <em>when</em> DST is observed during the year can differ.

In the US, DST begins on the first Sunday in April and ends on the last Sunday of October.
In many European countries, DST begins on the last Sunday in March and ends on the last Sunday of October.
In Israel, DST begins on the last Friday in March (I think?), and the end date varies by year.

And, as zem probably knows, the Southern Hemisphere observes DST during entirely different months of the year. And, of course, there are lots of places that don’t use it at all.

So, if there’s anyone seriously thinking about submitting a patch to do this, a request: <strong>please</strong> give the user an option to set when DST begins (or ends), if ever. Or better yet, make it so you can toggle yes/no with an option like “Is DST currently observed in your time zone?”

Thanks!

Mary · 2005-11-02 19:35:18

Elenita, it doesn’t matter actually, its a setting you determine, not arbitrarily turned on and off at set times.

Elenita · 2005-11-02 19:37:50

Ah, thanks, Mary. I feel better now.

TheUsability · 2005-11-02 19:42:12

we still haven’t fixed the problem that old articles switch time as soon as you change dst / gmt offsets. that still sucks.

KurtRaschke · 2005-11-02 20:08:46

Earlier I said that since I was in the same time zone as my server I didn’t have to muck with Textpattern’s time zone settings at all—in fact I’ve just realized that I do have to turn Textpattern’s “daylight saving” thing on/off on the appointed days.

It seems a little silly since my server already knows what time it is in my time zone—shouldn’t there be a way to have Textpattern just use the server’s local time?

Note that I’m not suggesting that Textpattern store times in the DB as anything other than GMT—times would stil be stored in the DB as GMT, and when TXP needs to display it, call <code>strftime($ts + date(‘Z’))</code>. Note that <code>date(‘Z’)</code> returns the server’s offset from GMT as understood by the OS.

This is essentially replacing Textpattern’s preference selections for time zone and DST with the call to <code>date(‘Z’)</code>. Maybe make an option in the time zone list labeled ‘Automatic’?

By doing this, users whose are in the same time zone as their server wouldn’t need to muck with a separate set of time zone settings for Textpattern. As long as their server has the right time zone and DST settings, then Textpattern will also have the correct time.

Gregarius, a web-based feed aggregator written in PHP works this way—by default it assumes that the user is in the same time zone as their server, and then it allows the user to specify an offset in terms of the server’s local time. I find that to be a logical, straightforward, and convenient way of doing things.

-Kurt

Last edited by KurtRaschke (2005-11-02 20:10:47)

Textpattern CMS

Textpattern CMS support forum

#16 2005-10-31 22:51:25

Re: [issue] Daylight Saving

#17 2005-10-31 23:04:40

Re: [issue] Daylight Saving

#18 2005-10-31 23:23:13

Re: [issue] Daylight Saving

#19 2005-10-31 23:28:22

Re: [issue] Daylight Saving

#20 2005-11-01 01:51:27

Re: [issue] Daylight Saving

#21 2005-11-01 04:14:23

Re: [issue] Daylight Saving

#22 2005-11-01 18:18:05

Re: [issue] Daylight Saving

#23 2005-11-01 21:09:16

Re: [issue] Daylight Saving

#24 2005-11-01 23:03:00

Re: [issue] Daylight Saving

#25 2005-11-01 23:31:46

Re: [issue] Daylight Saving

#26 2005-11-02 19:21:00

Re: [issue] Daylight Saving

#27 2005-11-02 19:35:18

Re: [issue] Daylight Saving

#28 2005-11-02 19:37:50

Re: [issue] Daylight Saving

#29 2005-11-02 19:42:12

Re: [issue] Daylight Saving

#30 2005-11-02 20:08:46

Re: [issue] Daylight Saving

Board footer