Date Based URLvar problem with time offset

mrdale · 2008-11-09 16:54:19

> ruud,wet.

Let’s get this solved one way or another.

saccade · 2008-11-10 09:07:52

Here a first part of my thoughts about time handling:

Timestamp and DST-setting

When calculating the database-saved value for a timestamp txp doesn’t take the value as showed in the formfields, but takes into account the current DST-setting in preferences (and the timezone) and recalculates the time to be saved.
Also, when publishing the timestamp, txp will re-calculate the database-saved value including the current DST-preference.
It does so for every value – regardless whether this value actually will be (in the future) or has been (in the past) subdued to the current DST-setting/preference.
This behaviour leads to a change in the shown values (time as text) every time you change the DST-preference.
And also in the publishing time, if you provide future publishing by setting a timestamp in the future.

Example:
1.
You write an article – published immediately – in summer with DST-on:
“Just – exactly at noon – finished my long term project. (written 2008-07-17 12:01)”

This will be published properly in summer.
But in winter (e.g. now) when DST isn’t on any longer your article will be shown this way – incorrect:
“Just – exactly at noon – finished my long term project. (written 2008-07-17 11:01)”

Here – for a critical reader – it will irritate, that you obviously wrote this article an hour before noon.
But sometimes it’s very important to have the correct time. Just mention you comment on a soccer game – and later it seems that you knew the result an hour in advance ;-)

Next summer (with DST-on) the indicated time will be changed again.

2.
This shift in time will occur on both levels: showing the time as text and calculating the publishing time.
If you write an article in summer – DST-on – with a timestamp to be published in the future in winter – DST-off – it will be published an hour before the time you had in mind.

This behaviour is a tremendous problem, if you do a calendar with textpattern.
Example:
I have a calendar (using a modified mdp_calendar plugin) where each event is represented by an article.
The event’s date and time is provided by the timestamp. The timestamp is used for two essential things:
1. Controlling when an article/event will be regarded as future and when it will be regarded as past.
2. Showing the date and time of the event (so the authors don’t have to insert multiple times but only once in the timestamp).
The current DST-change-problem will change all my events’ time – e.g. concert starting a 8 pm will be announced starting at 7 pm or 9 pm depending on when I created the file.

The main problem of handling the DST in txp is the following:
txp “normalizes” current time entries based on the current DST and somehow mirrored to GMT using the timezone.
timezone-implementing is not a problem for it won’t be different for past or future articles.
But DST-implementing based on the current DST-state is erraneous, for it doesn’t apply to all times but only to a distinct arbitrary period of time.

Most concepts first think about including those arbitrary tables of DST based on location. But that’ complicated. Not every DST-state is already known, there may be changes, and it’s a system beyond logic.
But we don’t need central knowledge about DST.
It will cancel down as in a mathematical formula or division:

The most simple solution:
When entering any time – whether automatically or manually – we (human authors) always think of the numerical value, not a base time behind.
publishing/written at 10:00 always means 10:00, whether in summer/DST-on or winter/DST-off.
So the timestamp should reflect this numerical value – whether taken from the automatically provided (=actual) time or entered manually, the DST-state behind this value is of no interest (except if you should want to explicitly tag the time as “summertime”).
Only for the actual system time (and thus publishing or hiding an article) the current DST-state has to be accounted to get the correct actual time out of GMT or whatsoever the server gives as time.

DST-preference in txp only is of interest to get from the server-provided time to the actual valid time. If your server gives you GMT, you will need both: timezone and DST.
If it gives you your correct local time with DST included you won’t need either of them.
So it is important only for the administrator to know his actual local DST-state and if it is to be activated in preferences or not.

Again in short:
1. For saving the time in the database and for indicating/showing an article’s time DST is not to be calculated – for it is already contained in the actual time or the time I have in mind.
2. For the current system time (and thus for the time when an article will be published) DST-preference has to be accounted – based on what the server provides as the time base.

saccade · 2008-11-10 11:59:25

Another essay, a little more systematic:

First a difference in terminology:
diachronic time = information about time(s), which can be in the past or in the future. Even the current time – for it is “past” after 1 second.
Timestamp and indication of time (time as visual text) are diachronic.
Diachronic times do not necessarily follow the current DST-state for they may have their own DST-state different from the current.

“current” = now.

synchronic time = the time which is actual just in this moment. There is only 1 synchronic time and it has the current DST-state.
This time ist to be used for publishing or hiding an article.
The servers provided time plus timezone and DST-state make the effective, actual current time, which has to be compared with the diachronic (!) time stamps to find out if an article is published or not.

Now my thoughts:

The problem

1.
1.1 txp does only know 1 frame (or better terms of reference) for “time”: the actual synchronic time which is calculated from server time, timezone and DST-preference.
1.2 txp calculates all times with this single term of reference: (a) the time it will store in the database and (b) the output of time in text in articles.

2.
2.1 Publishers/Authors but know (if there is DST) 2 (!) terms of reference for time: (1) time with DST in summer and (2) time without DST in winter.
2.2 But both are normally handled as “time” and normally there is no explicit definition, if e.g. 10 o’clock is meant with or without DST. It’s simple 10 o’clock under the valid circumstances. It is silently presupposed. Thinking that way is diachronic.
Example:
If I set a timestamp for August, 17, 10 o’clock, I silently speak of MESZ (middle european summer time, DST on), if I set a timestamp for December, 17, 10 o’clock, I seilently speak of MEZ (middle european time, DST off).
In fact it is of no interest, which DST-timesetting it is. Even if DST tomorrow will be cancelled by law or extended to december, I normally still want to have my timestamp at 10 o’clock.
It is supposed that entered times always mean the actual current time (what is showed on the clock) – independent of DST on or off behind it. This also is valid for the automatic timestamp.

3. the timestamp is of interest in two ways:
3.1 for publishing or hiding an article based on it’s settings.
3.2 for indicating/showing it’s time of origin (time as text).

4. Here now there is a confusion with the different frames or terms of reference:
4.1 For publishing there indeed is only one frame = the actual current time (current DST-state included).
4.2 But for indicating past or future times (see 3.2) there are different terms of reference (like 2.2): Some with and some without DST in effect.
4.3 Because txp only knows of 1 frame/term of reference it changes all time indicators like 4.2 with every change of it’s algorithm. And so erraneously changes time(stamp)s to which the current DST-sate doesn’t apply.

Solution

5. This problem can be solved by separating “publishing time decision” and “time indication/timestamp”.
This way the different terms of reference can be taken into account (and “cancel out” as in a mathematical term).

5.1 Completely separate:
a) the actual indicated time (or manually entered value) will be saved in the database without any further calculation. This value will later also be indicated without any change as the “published”-date.
b) for publishing time the unaltered timestamp will be compared to the actual calculated time in which DST is included based on the preferences.

5.2 Partly separated:
a) Only timezone-settings are taken into account for the timestamp to save in the database. This way a later following change in timezone would be possible. DST should be left out in saving any time.
for publishing the timezone-corrected timestamp then should be compared to actual (synchronic) time as above (5.1b).

6.
The preferences should get more options, for there are different times provided by the server:
For taking into account servers which deliver a DST-corrected time there should be the two options as now and one more:
a) timezone
b) DST on/off
and a new
c) Servertime includes DST – yes/no

If c) is NO, then b) will take effect
If c) is YES, then b) should automatically be deactivated.

Last edited by saccade (2008-11-10 12:11:32)

Bloke · 2008-11-10 12:18:15

Owww, brain hurteeeee….

But your system is laid out with such conviction and depth, I vote for it. At the end of the day, publishing articles to appear or expire at certain times would be a helluva lot easier if I could specify an absolute time when that event occurs and leave the server admins/politicians to have a bun fight over when DST occurs. Or doesn’t.

saccade for Timelord :-)

Last edited by Bloke (2008-11-10 12:20:29)

saccade · 2008-11-10 12:29:37

Thanks :-)
(slowly remembering my name after fighting with those time description issues, fortunately it is written anywhere and won’t change by any setting) :)

mrdale · 2008-11-10 16:33:37

This sounds quite rational…

I suggest we show the simple timestamp fields by default in the UI and move the rest of the confusingly named “more” items to a “time options” which is hidden.

On a side note… I’d like to know more about your mdp_calendar hacks. I routinely use a “hacked within an inch of it’s life” version of mdp_calendar myself.

saccade · 2008-11-10 21:03:17

@mrdale
I’m putting my documentation together (begun and stuck). You can see an example here . Basically I did some category tweak to specify and style different types of entry (in the example different communities which post their events, one in red, the other in blue, common events in green). Also some modifications to get finer styling (like coloring sundays of a week).

Last edited by saccade (2008-11-10 21:05:23)

mrdale · 2008-11-13 23:01:25

tapping feet… whistling….

ruud · 2008-11-17 13:19:01

Personally, I set both server and TXP to use GMT/UTC without DST and let the user see the time in the timezone he/she has configured on his/her own system using Javascript.

To solve this in TXP, you have to ask yourself how far do you want to go… should TXP allow for the option of posting in different timezones (what happens if the site author moves to a different timezone?).

saccade · 2008-11-17 15:31:08

I had in mind a far scenario too.

But for now I’d like to have a solution which will be practically and which would solve the DST-shift-error for past/future times.

The GMT trick sounds good, but will it work with calendar plugins too?
And – most important – is it possible that an author who doesn’t want to bother about time calculations could enter his correct time (that means: will the time be calculated backwards to meet GMT/UTC correctly)?

Obviously this solution needs a timetable which will know the correct DST-state for any past and future time.

So as a first thought: A solution should be capable of cancelling out DST-state-management for any diachronic (past and future) time – and only need the correct DST-state for the synchronic time valid in this moment (that is a single and always distinct state).

A solution along my proposal means: No need for any DST-table! Never!

And regarding a far solution:
For those who will likely change their server time zone of course there must be a reference. timezone-chancging won’t happen very often. I could imagine something like this: There could be an additional tag in the database which will specify the timezone (not DST!) which has been active when creating/editing an article. This will be enough.
When someone changes his server timezone (or the timezone he/she wants to show all time indicators in) there could be a one time button with a routine “recalculate timestamps” based on the timezone-tag saved in the database and the currectly active timezone.

A more far solution could be to include a timezone tag for every timestamp AND let users/authors choose/change their timezone when editing by a simple list. This of course requires an additional output which will specify which timezone the author lived in when creating/editing an article.

In every case: Leave out DST from any calculations. It’s only real place is the current synchronic time.

(I hope I didn’t make any mistake now. Just a fast thought. Have to think about again.)

Last edited by saccade (2008-11-17 17:11:02)

Bloke · 2008-11-17 16:20:43

ruud wrote:

Personally, I set both server and TXP to use GMT/UTC without DST

That’s not a bad solution for those of us who can actually set our server’s time prefs. When the hoster controls it, all bets are off!

mrdale · 2008-11-18 05:35:12

ruud> BTW some feedback.. Mary’s hack works… and the variation you offered (thanks) did not.

Textpattern CMS

Textpattern CMS support forum

#13 2008-11-09 16:54:19

Re: Date Based URLvar problem with time offset

#14 2008-11-10 09:07:52

Re: Date Based URLvar problem with time offset

#15 2008-11-10 11:59:25

Re: Date Based URLvar problem with time offset

#16 2008-11-10 12:18:15

Re: Date Based URLvar problem with time offset

#17 2008-11-10 12:29:37

Re: Date Based URLvar problem with time offset

#18 2008-11-10 16:33:37

Re: Date Based URLvar problem with time offset

#19 2008-11-10 21:03:17

Re: Date Based URLvar problem with time offset

#20 2008-11-13 23:01:25

Re: Date Based URLvar problem with time offset

#21 2008-11-17 13:19:01

Re: Date Based URLvar problem with time offset

#22 2008-11-17 15:31:08

Re: Date Based URLvar problem with time offset

#23 2008-11-17 16:20:43

Re: Date Based URLvar problem with time offset

#24 2008-11-18 05:35:12

Re: Date Based URLvar problem with time offset

Board footer