You are not logged in.
Preference or No? I’m for your hack. Let’s get it in the core. I’m sick of applying hacks to every site I have that uses a calendar.
…otherwise, let’s remove DST and Timezone altogether, as they’re functionally pointless.
Maybe I’m wrong here (I just chime in because there seems to be a change in the time-handling), but DST behaviour in Textpattern is a problem in general, because DST-setting now does change all dates (or timestamps, back and forth), even when they were created in a different DST-period.
In my opinion DST-setting should be left out in calculating timestamps (just take the current valid time or the manually inserted time) and only be taken into account when calculating the current active time. Timestamps shan’t change ever (except willingly and manually) and they always should reflect in numbers what time has been actual (for past times) or what is estimated as the actual time in future.
E.g.: If I write now (non DST) an article which should be published (and should show the time 10 o’clock!) next June, 1st, 10 o’clock (DST presumably active – but this could also be changed by law), I don’t want to know or think about it’s time-algorithm. Whether DST or not I mean 10 o’clock. At the moment I need to set it to “9.00” because otherwise txp will change it to “11” when DST-setting changes.
The other way round an article which is now shown as “published 10:00” in next summer will be shown as “published 11:00” – that is extremely irritating, not to mention the hassle if you have a calendar like mdp_calendar.
Edit: I have written those reflections in german, should I post them or try a translation?
Last edited by saccade (2008-11-07 21:07:40)
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.
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.
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.
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.
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:
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.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.
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.
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).
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:
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)
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)
(slowly remembering my name after fighting with those time description issues, fortunately it is written anywhere and won’t change by any setting) :)
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.
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)