[issue] Daylight Saving

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)

hedning · 2006-04-12 16:55:53

There is a quite good explanation: http://www.blivet.com/blog/2004/03/21/and-wordpress-is-driving-me-to-textpattern

KurtRaschke · 2006-05-08 18:30:05

I’ve been giving this a fair amount of thought over the past few days, and I think I’ve come up with a workable solution to this. Presently, TXP stores a GMT timestamp for every post. To display that as “local time”, TXP uses a user-specified offset. However, this assumes that that user-specified offset is the same now as it was when the post was created. Unfortunately, there are several cases where this is not true. Daylight saving time, summer time, and permutations thereof are the most noticeable case.

When a user changes TXP’s time zone settings due to the start or end of DST, post timestamps for old posts seem to “jump” forwards or backwards—because TXP now applies the new GMT offset. Because TXP does not store the current GMT offset in effect when a post is created, it must assume that the current offset for the site at the time that the article is displayed is correct—and in this case it is not.

There is also a more subtle bug. My TXP installation, for example, is currently set for GMT -0500, Daylight Savings ‘on’ (US/Eastern time zone). However, if I were to write a post while travelling in another time zone (say, for example, GMT +0100), I’d over-ride the timestamp displayed on the ‘write’ tab with my current local time. TXP would then use the site’s defined GMT offset to get the appropriate GMT timestamp, which will be wrong. Of course, TXP assumes that the value entered is a local timestamp in the GMT -0500 time zone, and has no way to know that I am actually in GMT +0100. Now, the end-user will probably never see the effects of this part of the bug, but it does mean that timestamps in the feeds will be wrong for articles created in this situation.

The solution is clear. TXP must store, for every post, the current local time zone. TXP must furthermore pre-populate this field with the site’s current local time zone, but make it accessible to the user for cases where the user’s current local time zone is not the same as the site time zone. Finally, the article timestamp tag needs to have an option allowing the site designer to specify the time zone used for formatting the timestamp—GMT, site local, or article local.

The article GMT offset field probably won’t get much use except on sites with authors in multiple time zones or who change time zones frequently, so I would argue that it probably belongs on the “advanced options” panel, so as to not confuse the majority of users.

As to implementation specifics, this requires adding a SMALLINT to the textpattern table. The upgrade script should go through and pre-populate that field with the site’s current GMT offset. For sites with DST, that’ll mean that we’ll get some of the timestamps wrong, but that could always be resolved by manual editing, and otherwise there’s no way for us to discover after-the-fact what GMT offset should have been applied to a post.

I’d be glad to implement this and release a patch if there’s any consensus that this is the right way to go.

-Kurt

Last edited by KurtRaschke (2006-05-08 18:35:53)

Mary · 2006-05-08 23:59:00

old articles switch time as soon as you change dst / gmt offsets

I’ve thought it about it too, but really it makes no sense; the “time” shouldn’t remain the same when I swap timezones, that’s the nature of how our timezone system works.

When I chat with Alex in Australia, usually it’s “tomorrow” for me where he is and “yesterday” for him where I am. If we’re on a funny date, it could be the April 31st where I am, but May 1st where he is, in two completely different months. If it’s New Year’s Eve where I am, it is next year where Alex is.

If I post an article at Monday, May 8th, 2006 5pm where I live (GMT -6, MDT), the GMT time remains constant. Where Alex is, I have posted it Tuesday, May 9th, 2006 9am (GMT +10, EST). It occurs at both times, both times are correct.

Now let’s say I teleported to Berlin, Germany (GMT +1, CEST), and I change my timezone accordingly. That places my article at Tuesday, May 9th, 1am, which is still accurate.

I think the current confusion is eleviated somewhat if we state somewhere the timezone that the site uses for dates used as a reference. I’ve personally been using GMT precisely because there’s no time switch that way.

Perhaps it is better if we simply change how “now” and “month” works, to always use GMT time (apply no offset), rather than a date offset (which is for user convenience, since that’s what time it is where we live). That way, articles never appear and disappear, and would be available at the correct and exact time for everyone in spite of the crazy way timezones work.

How would that work in ui implementation (the article tab “date” fields, etc)? I think we can keep the interface the same as it is (so the user there is no change), but implement a date conversion function when it is actually posted (to convert from the user timezone to gmt).

For sites with DST, that’ll mean that we’ll get some of the timestamps wrong, but that could always be resolved by manual editing, and otherwise there’s no way for us to discover after-the-fact what GMT offset should have been applied to a post.

Agreed. No matter what solution we come up with dst will screw us over somewhat, but I don’t think it can really be avoided, just lessened. This kinda change of how dates are handled is pretty big, so it’s likely a 4.1 thing.

KurtRaschke · 2006-05-09 00:26:48

I’ve thought it about it too, but really it makes no sense; the “time” shouldn’t remain the same when I swap timezones, that’s the nature of how our timezone system works.

I have to admit that I still don’t get that, although it may just be how I’m thinking about it. I would expect TXP to display article timestamps in the local time zone of the author. If, as I’m writing an article, the clock on the wall says 1:23 PM, then that’s what I’d expect the TXP timestamp to say—now, and after a change in DST settings. Of course, TXP still needs to know the GMT offset that was used so it can produce a GMT timestamp for the feeds. The truth is, I can’t come up with any reasonable justification for this behavior; it’s just what seems intuitively right. Most likely I’m just thinking about it wrong.

I am getting the feeling that there are two schools of though on this—one time zone for the entire site, as you describe above, and one time zone per article, as I describe. I’m not sure that there’s any way to reconcile the two.

I’m getting fairly close to throwing up my hands and just using GMT for everything as well.

How would that work in ui implementation (the article tab “date” fields, etc)? I think we can keep the interface the same as it is (so the user there is no change), but implement a date conversion function when it is actually posted (to convert from the user timezone to gmt).

Sounds reasonable to me.

-Kurt

zoeglingjulian · 2006-05-09 07:43:04

I second Kurt’s opinion. I think his “clock on the wall” explanation describes it rather well…the time somehow sets the “mood” for an article. Sometimes it’s just different if it was written in the middle of the night than, let’s say, in the morning. And that should remain the same, always.

I don’t care if it was morning for a reader from America while I wrote the article—it was written at nighttime, and that should be visible.

There’s the “rsx_time_of_day” plugin, for example. It displays time in a human-friendly format, like “Just after midnight” or “during lunch break”. Do you see what I want to express with “mood”? There’s a difference between writing something in the lunch break or in the quiet hours of the evening. At least for some sites.

KurtRaschke · 2006-05-09 17:19:08

Julian, Mary:

I think it comes down to giving the site designer a choice as to what time zone to use when parsing the <txp:posted /> tag.

Let me give an example scenario as to how this would work. Suppose that, as I proposed above, TXP stores a GMT timestamp and GMT offset for every article, and the GMT offset is user-modifiable.

As above, let’s say that my site GMT offset (the existing “Time Zone” setting in the TXP prefs) is set to GMT -0500, Daylight Savings on (so the actual GMT offset is -0400).

If I post an article at 13:20, all will be well. The article time zone, being unchanged, will be left to the default, and so the article timestamp will display as 13:20 on the site. Now, what do we want to have happen when DST ends?

Should the timestamp change to reflect the new ‘site’ timezone, or should it continue to reflect the ‘article’ time zone?

<txp:posted tz="site" /> would return 14:20, as the article time stamp would be converted from GMT using the current offset for the site, which changes due to DST. This is TXP’s current behavior, which seems to have started this entire discussion.
<txp:posted tz="article" /> would return 13:20, as it always has, because the article time zone never changed.

Yes, it’s more complicated. Yes, it introduces more decisions for the site designer. Yes, it will generate support queries. Yes, it’s one more piece of data for TXP to pull out of the database when displaying an article. But it will put the issue of jumping timestamps to rest, now and forever.

Site designers will be able to choose whether they want timestamps to be shown in the time zone of the site (which may change due to DST or changes in physical location), or in the time zone of the article (which is an immutable trait based on the physical location of the author).

I suspect that sites with multiple authors (or a single author) who are generally all in the same time zone will set TXP’s time zone to whatever is convenient for them, and not have to worry about it again. For them, the solution I’ve proposed above won’t change much, with the exception of being able to stop the “jumping dates” problem with DST.

For international sites, though, this could be a significant improvement. As users from various time zones add articles, they’ll be able to indicate their local time zone, so that TXP can properly compute the GMT time from the local time that the user enters on the ‘write’ tab. From there, based on the goals of the site designer, that timestamp can be displayed in the author’s local time zone, GMT, or whatever TXP’s site time zone is set to.

Also: I recall having seen Alex point out earlier the issue of date-based permalinks. I would argue that they should just be based on the GMT timestamp. It’s easier that way. For that matter, anything timestamp-based that occurs ‘behind the scenes’ should just use GMT. This is really mainly a matter of how dates are formatted for display to users.

Finally, we may not necessarily have quite such a problem with DST; we could always supply users with a conversion tool that would allow users to enter their DST rules, and change the offsets for articles falling within those date ranges. It could be done as an admin-side plugin.

-Kurt

Last edited by KurtRaschke (2006-05-09 17:26:32)

Textpattern CMS

Textpattern CMS support forum

#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

#31 2006-04-12 16:55:53

Re: [issue] Daylight Saving

#32 2006-05-08 18:30:05

Re: [issue] Daylight Saving

#33 2006-05-08 23:59:00

Re: [issue] Daylight Saving

#34 2006-05-09 00:26:48

Re: [issue] Daylight Saving

#35 2006-05-09 07:43:04

Re: [issue] Daylight Saving

#36 2006-05-09 17:19:08

Re: [issue] Daylight Saving

Board footer