[issue] Daylight Saving

Mary · 2006-05-10 06:18:44

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.

That kind of scenario only applies to specific kinds of blog/journal entries (like if we make reference to “today” or “this evening”). I’m not saying that makes it irrelevant, but we need to keep perspective.

When we talk about how dates and times work we are referring to the entire system, not just how “posted” displays the article’s time (these things tend to work like dominos):

Daylight Savings Time
Timezones and then switching them later
Switching servers or the server’s timezone gets reset/changed
“Relative” dates and times (“today”, “tomorrow”…)
Any others you can think of?

DST is a bane upon man-kind. Apparently they’ll be changing the length of it next year (where I live). It’s not confusing enough, we gotta screw around with it some more!

Storing a timezone offset per article wouldn’t be wrong per se, but it does make things potentially more complicated and that fact cannot be overstated. For instance, if you do that and then display the date/time, you should also be stating exactly what timezone is being used, otherwise it is meaningless.

These are the kind of things that need to be worked out – use cases, possible problems and preventions and workarounds, what that means to the average user (this one is a big deal), etc – before a patch or change is realistic.

saccade · 2006-12-07 21:15:52

I see.
Brainwork to do.
Note: Sorry, the next post is long and at the first glance complicated. But I tried to work it out and hope it is properly thought out.
Unfortunately English is not my native language so it might confuse some thoughts. Discussion will help. Meanwhile I did a german version too
I post it in several parts for better referring and printing. Hope this wouldn’t offense anybody.

A What is time?

There is not one time for all.

We have to distinct different forms of time:

A-0 (you can skip this philosophical preface, it’s only a frame for a full picture of the rest)
There is time itself.
It runs from a beginning, which we can’t grab, to an end, which we also can’t grab.
So for us there is no real beginning or end of time. And thus there is also no real measure or unit.
In between the only thing we can tell exactly are relations: We can say “this happened before that” or “this is – referred to a base point at that (relative to the basepoint) time”.
And the problem is, that there are different relations. We can relate to day-night-cycle, or to before/after any incident. And we use different units.
For a better handling we now set one point absolute: The following number 1:

A-1
There is an absolute time.
It is a helpful construction to get the “time itself” into manageable terms.
We can count “absolute time” in a single unit (!) for example in seconds from one referring point, lets say the beginning of 1970.
Every incident (e.g. post) has it’s unique place on one point of this scale.
In relation to this scale (!) it can be labelled with a unique “tag” or number, which won’t change, wherever you are – or whatever “time” it is actually.
The absolute time has a consistent, straight, let’s say eternal structure with no differences or breaks within the scale.
In its system of numbers (its code) it can reflect consistent (!) cycles like sun or planet movements, day and night, but it needn’t. It also could use a quite different unit. The only restriction is: There mustn’t be any gaps or duplicates.
Absolute time has a logical order and a necessarily sequence.

Its advantage: Time is comparable and exact and can easily be ordered and calculated.
Its disadvantage: No one can really imagine what time it is (e.g. “second 462385635 since 1970”).

A-2
There is a conventional time.
This time is, what a number of people define as their referral time. Everything planned, arranged, compared im terms of time will be related to the current convention in force.
Conventional time is separated into different scales and units – counted with different numbers, specifying hours, minutes, seconds and a calendarious date.
Not to mention: even different calendars are used. (Months and years differ not only in naming, but also in division and length)

Fortunately the time system within a day is not very different (at least I don’t know of a real estimated alternative).

But there is one difference which is important here: The convention to have a wintertime and a summertime.

Conventional time is a contextual thing. It belongs to distinct areas and distinct ranges of time (means: how long e.g. summertime lasts). These areas and ranges are defined and in this regard somewhat random, not logical and necessarily.
It even needn’t to be periodic. DST began at some date and it is not sure, if it will be continued.
So the conventional time is not consistent, it is not straight but it has breaks and changes: from wintertime to summertime and vice versa.

Its advantage: Conventional time gives an impression in which context something happened: Summer, Winter, day or night, early or late.
Its disadvantage: Times are comparable well only if you belong to the same context. If spread over different contexts /time conventions and timezones) the breaks and exceptions (e.g. missing or duplicate hours caused by DST-change) and maybe different scales will cause confusion.

A-3
The conventional time has an additional factor of change: There is a local time.
Out of practical reasons the conventional time tends to start with a certain numer in the morning or in the night. People all over the world like to have sunrise at e.g. 6 o’clock – not at 23 o’clock. So conventional time differs in the parts of the world, the timezones.
So the conventional time is always expressed in a local time in which the conventions differ (winter time or not, atsrted/ended differently).

A-4
The local time itself of course refers to the location. If, like now in the web, communication spreads over such huge areas, that different timezones are involved, the partners of communication refer to different conventional times based on their location. And if you communicate, you have to share, which location you refer to.
So there is a local time of the website (normally the local time of its owner). (That can but must not be the local time of the server!)

A-5
And there is a local time of the user wherever he is at the moment. Moreover: there are multiple local times of multiple users.

A-6
So one incident in the absolute time spreads into different conventional time systems and into a bunch of local times around the world.

he same in german

Last edited by saccade (2006-12-09 08:07:46)

saccade · 2006-12-07 21:20:12

B Now let’s come to textpatterns time management:

In the discussion so far all of the above listed times appeared.
Some misunderstandings or confusion resulted from a different meaning or understanding of terms, e.g. local time.

So I try to apply the above time-forms to the times we need in txp:

B-1
What is currently saved in txp’s database is the absolute time [see A-1].
This one correctly won’t and shouldn’t be changed.
This timestamp guarantees that we can figure out which post came after or before another. Completely regardless, in which place over the world or in which local conventional time of the user it has been posted.
So far this is right and shouldn’t be changed.

B-2
What is currently also used is a conventional time [see A-2 – but not fully! see below].
This time is currently based on the (imaged) location of the website [A-4].
It is set by the timezone and the DST-setting, which also identify the conventional times type or rule.
The conventional time will be calculated from the db-timestamp [=coded in absolute time] to which the timezone+DST-setting will be applied.

NB: To keep this time in correlation with the “real world time” is on behalf of the admin. (more to this point later)

Here one of the main problems arises:
txp only uses one aspect of conventional time: It only knows the actual current conventional time rule. (And it is “one for all” or a 1:x-relation.)
It doesn’t use an important other aspect of conventional time: the contextual aspect. It has not the smallest memory which contextual conventional rule was in effect, when the article’s timestamp has been set. (The time rule in effect is truely a 1:1-relation.)
So here really happens a change in the moment when you change the timesettings: The original information of time (= absolute time + contextual conventional rule) is lost. It was only present in the combination of absolute time and timesettings and thus is changed/lost.
By applying the actual current conventional time rule (e.g. wintertime) to timestamps which have their origin in another timerule (e.g.summertime) a false information is generated – and it will be changed again and again with whatever change of timezone/DST.

As already said:
If I say: “John finished his 2006 summerschool at 3 pm” it is always 3pm. Regardless of whether it was in wintertime or summertime, because I refer to the conventional time, the time valid at the moment of the incident.
I would never refer to the absolute time and say when I’m in wintertime: “John finished his 2006 summerschool at 2 pm”. And later if I’m myself in summertime again next year I should say again “John finished his 2006 summerschool at 3 pm”?

Scenarios, where a fixed conventional time is very important:

live comments, e.g. on sports events.
comments or articles about elections results (imagine a first projection that miraculously is stamped one hour before the election ends.
reports of a conference

B-3
At this point txp needs an improvement: the contextual conventional time (or at least the rule in effect) at the moment of setting the timezone has to be preserved [clarification needed, see this post]. And this has to happen on a per article/comment basis.

For a really useful working of our installations we need both categories of information about time:

The absolute time is needed for the correct sorting of articles – in other words: The relation between articles. And it is needed as a basis of time calculations, that is common for all. (It will ease the processing. Of course you could also take only the conventional times together with their name and origin, but then you would have to take into account all breaks and exceptions and so on, when translating one to the other.)
The correct (!) conventional time (or the rule in effect, correct individually for actual as well as for past as well as for future articles, means: per article/comment) is needed for the correct presentation of time in “posted”-information. And – much more ! – when articles have to be in relation to the actual real local time, e.g. in a calendar or list of events (see examples above).

So my conclusion: Both kinds of information have to be stored in the database.
And there is no way around that. For both keep an important part of information about the real time.

Discussion: We ought to think about if one of both is enough to calculate the other:
1. Of course in every case we need a sufficient table of ALL conventional rules which (have been used and will be used and) might apply.
With regard to the friendly user forum and the widespread audience of txp this should be no problem :-)
2. Now: Can we calculate one from the other?
Let’s begin with abolute time -> conventional time:
No. You cannot calculate, the conventional time, if you don’t know, which convention (rule) takes effect. There is only one way to calculate the conventional time from the absolute time: If we have additional information about the general convention that has been used by the author. (that is at least the location of the user/website at the moment, the timestamp has been set).
And the other way round – conventional -> abolute time?:
This is easy, provided not only the single digits/numbers are saved but also the rule in effect, actual shift or timezone/DST-code.

How to save the absolute and conventional time information?

B-3.0 Of course the absolute time should be saved as now. For example: (GMT) 12.00 additionally:
B-3.1 At least the actual real time expressed in terms/digits of the conventional time. For example here in Germany in summer: 14.00
B-3.2 Or the timeshift in effect regarded to the absolute time. For example: +2.00
(B-3.1 and B-3.2 are directly proportional and can be calculated in each direction.)
But B-3.1 and B-3.2 also lose information: If you are in timezone X+3 or X+2+1DST will be the same and will not be discernible later. If it is of interest, from which timezone something really comes, use the following:
B-3.3 Better: detailed info about contextual timezone (rule) and DST (that is the one in effect). So you can better imagine, where it was. The actual time then could be calculated from the absolute time together with the rules table. For example: GMT+1+1DST
B-3.4 Much better: Fully determined: real/actual time in digits and the abbreviated timezone/DST-code (or rule). For example: 14.00 = GMT+1+1DST

Edit: If you want to reduce redundant information and really bring it down to the essential bits of course B-3.3 is enough. Provided you have a definite unambiguous Definition of the rule. The real time expressed in numbers can then be calculated from the absolute time and the shift in effect, defined by the rule. It is a definite exact relation.

EDIT: If you want to avoid an additional field
If you don’t want to implement an additional field for the time in each article db-entry at least there must be a table which tells exactly where (info for all possible timezones) and when (exact date range) DST applies (was in effect). [see another post, where I suggest a table and mechanism like the language files.]
Then when it comes to presenting an article the absolute time has to be shifted along the actual timezone-setting and adequate in accordance to the DST-rule in effect at timestamp-time. (see B-4)
In this case we keep the restriction to only one active timezone in a txp-installation and there is no way to work parallel with different timezones (see B-5.2).
This would correct the bug and is better than nothing. But for I regard this as less useful and would like to have a full solution, the following thoughts base on adding a field which qualifies the time rule in effect.

B-4
Where do the different times apply to? What is their function?

Absolute time [1] has to be used for sorting, determines the sequence in which articles are presented, it will preserve the logical and historic order of articles and posts. Asolute time covers the relation between articles.

(Contextual) conventional time [2] has to be used for presenting (when an article is shown or hidden) as well as for showing time-information (=“posted”). Conventional time covers the relation of articles to the users time (real time).

the same in german

Last edited by saccade (2006-12-09 21:32:18)

saccade · 2006-12-07 21:21:39

B-5
If we come to the different views on conventional time, there are the following aspects:

B-5.1 considering a single timezone
At the moment txp manages the actual (not a past) conventional time in accordance to [A-4] above as the conventional time of the website. It is this time, we see e.g. below the write tab in the admin area. And this time is automatically used for the timestamp (which of course is saved only with its absolute time aspect as shown above).
This time then also is used for presenting all timestamps in the output.

Normally as a user I know, that I talk/write into this context. It’s another question if it is also my current time context. If I write a post to an american site, i normally am aware that they will show their time. If I want to state that it is late in the night here (I’m in Germany), I cannot use the time expressed in numbers, but I state it in words. So I would do also if I’m in a flight and cross a lot of timezones.

So regarding this aspect a change is in my view not really necessary.
It could without problems be enough with one single timezone setting, a “website local conventional time” (though its changes MUST be preserved).

B-5.2 considering multiple timezones
But of course I can easily imagine a multicultural/international site in which you want to present different local times too.
And that means we need to have a system of managing different rules that accompany a timestamp.
As we have to save the rule anyway and give respect to it on behalf of presenting and showing/hiding articles, the only real additional thing would be giving users an additional field to select their time-rule.
From this list they could choose which local user time [5] (=timezone) should be taken for the written/posted-info.
And if the timestamp is set manually für publication, it will publish, when the timestamp meets the actual real time of its chosen timezone.

Let me dream: We could have a list of posts or articles like this, each posted after only one minute:
“Hi, here is Gregorios” posted GMT, 15:33
“Welcome, good morning, my name is John”, posted EDT 8:34
“Hi, good evening, Gregorius and John, my name is Abdel, it’s a wonderful sunset in Teheran now”, posted IRT 17:05
Advantage: This would give an impression of the different local times
Disadvantage: If you arent’t customed with the timeshift, you couldn’t easily say if it was after a minute or after several hours.
Solution: With a doubly saved time you could present the reference absolute time if you like.
So it depends on what time information you really need or like.

Another scenario, in which you could imagine a mixed timestamp usage:
Lets say there is a german cultural institution working worldwide. It has a german website, where quite a lot of articles and posts are hosted. Of course it will use its timestamps with local time to determine articles for posted-info as well as for publish-at-stamp.
Now lets say there is a small dependance of that institute in Australia. This dependance has conferences and courses and presents them in a calendar. All the web-publication is done within the same txp-installation in german. This is in a different timezone than the audience of the dependance’s pages or section.
The problem is: How let articles be posted or hidden at local australian time?
It would be no elegant solution to calculate the difference separately and add it manually.
Much better would be a selection setting which means: “Use local time XX” for publication.
So the australian section would show for example australian time, the german section german time.

All this would be very nice of course and would make a very impressive way of visualizing internationalisation.
But I think it would be also a real big job to implement.

B-5.3 considering single, but changed timezone.
If a complete txp installation is moved to another timezone (one of the scenarios in the discussion so far),
the local time of the website normally changes.
With the current time-management, now all posts will be set to another time.
This will perhaps be ok, if it is of no interest at which local daytime something was written.
You might for example end up with all your existing users/posts seem to have posted deep in the night.

There is no chance to preserve the original time – unless you sacrifice your new local time and go ahead with the old and maybe far away timezone.

With a new time-management, that preserves the timezone/timerule in effect at posting time,
you could easily show all posts with their attached timezone, thus reflecting the correct contextual time for all posts, regardless whether they were posted before the move or afterwards.
You even don’t need a timezone-dialog, for the new timezone will be saved together with the timestamp, as well as the old timezone was saved with the former time.

For the correct order of articles it is no problem too, because the aspect of absolute time is preserved, and thus the relation between articles is consistent and correct, independently from which timezone you choose to be calculated on.

the same in german

Last edited by saccade (2006-12-09 08:09:00)

saccade · 2006-12-07 21:39:13

Some handling thoughts for the change:

If there is an additional field in $thisarticle which saves the actual time and or the timesettings,
it is of course a question how to deal with existing articles.

If old articles are all within the same time rule, this should be easy: giving them all a chosen timezone/setting and calculating the matching real time.
If they are of mixed rules (e.g. some within summertime, some within wintertime) maybe a table can help which compares dates and applies the right rule and calculates the correct conventional time. But this of course is only possible if they are consistent regarding all other timefactors.
If they are really mixed, timezone field has to be set up manually for each old article.

Maybe there could also be an additional setting, which defines which field should be used for showing/hiding articles:

conventional time
a single timezone setting applied to the absolute time, could be the same or an offset like now. This option would restore the behaviour that we have now.

DST
Above I once mentioned the manual setting of timezone and DST in the admin settings.
Here I have another idea:
Why don’t we (the friendly users of txp-forum) create a date/timetable with all of the existing rules for DST in the timezones (for several years, and of course maintenance/update it when some rules change – DST is a arbitrary thing) and apply them the same way as now language files are implemented?
Then it would be enough to set the valid timezone and from time to time pdate the rules table.
Then the DST-setting could be implemented automatically by taking the correct dates and changes from this table and apply DST automatically.

the same in german

Last edited by saccade (2006-12-09 08:09:36)

saccade · 2006-12-10 00:55:23

After some time of thinking over and over the different times and the places, where they have to be calculated or used, I have to make some clarifications :

B-1 revisited
What is currently saved in txp’s database as the timestamp is the absolute time [see A-1].
The timestamp guarantees that we can figure out which post came after or before another. Using an absolute time ensures consistency – regardless, in which place over the world or in which local conventional time of the user it has been posted.
With this timestamp each article can be published (or unpublished) in the very right moment.
This “time” correctly won’t and shouldn’t be changed (except willingly because of a new positioning of the article within the timeline).
So far this is right and this part of txp shouldn’t be changed.
Unfortunately the timestamp is calculated incorrectly in some cases. (see below B-2 revisited)

B-2 revisited
What is currently also used is conventional time [see A-2].
It is used where time should be filled in as well as in the output.
All views on time are determined by a single timerule which is made in two settings by defining timezone and DST-setting. This one and only rule is used on the whole website. So the conventional time is based on the (imaged) location of the website [A-4].

NB: To keep this time in correlation with the “real world time” is on behalf of the admin. (more to this point later)

The conventional time thus is the way of handling times in txp. The absolute time is only internally.

But exactly in the current way, how the use of conventional time is implemented in txp the main problem is located:

txp only uses one aspect of conventional time: It only knows the actual current conventional time rule. (And it is a “one for all”-relation.)
This rule is applied to all timestamps. All timestamps are calculated according to the actual rule. txp doesn’t take into account if a timestamp ought to be connected with another rule (e.g. summer- instead of wintertime and vice versa) to be in a correct relation to the conventional time of the user.
This way txp neglects an important other aspect of conventional time: the contextual aspect.
And this leads to false timestamps:

I prepare articles for publishing – one for January and one for July. Each should be published at 10:15 a.m. german time. So I will enter “10:15 am” and the correct date into the timestamp-field. My timezone is Germany GMT+1. Now it’s wintertime. In July it will be summertime/DST. The internal timestamp will be in both articles “9:15 am”. But that’s not correct! It is correct only for January. In July, when it is 10:15 in Germany, the GMT will be correctly “8:15 am”!

txp does not keep the smallest memory which contextual conventional rule was in effect, when the article’s timestamp has been set.
So here really happens a change in the moment when you change the timesettings: The original information of time (= absolute time + contextual conventional rule, this information is only present in the combination of absolute time and timesettings.) is lost.
By applying the actual current conventional time rule (e.g. wintertime) to timestamps which have their origin in another timerule (e.g.summertime) a false information is generated – and it will be changed again and again with whatever change of timezone/DST.

Scenarios, where a fixed conventional time is very important:

live comments, e.g. on sports events.
comments or articles about elections results (imagine a first projection that miraculously is stamped one hour before the election ends.
reports of a conference

B-3 revisited
At this point txp needs an improvement: txp needs to keep information on the contextual conventional time that frames the timestamp. In the best way this has to happen on a per article/comment basis.

For a really useful working of our installations we need both categories of information about time:

The absolute time is needed for the correct publishing and sorting of articles – in other words: The relation between articles. It is needed as a basis of time calculations, that is common for all. (It will ease the processing. Of course you could also take only the conventional times together with their name and origin, but then you would have to take into account all breaks and exceptions and so on, when translating one to the other.)
The correct (!) conventional time (or the rule in effect, correct individually for actual as well as for past as well as for future articles, means: per article/comment) is needed for the correct presentation of time in “posted”-information and when the timestamp will be set manually. And – much more ! – when articles have to be in relation to the actual real local time, e.g. in a calendar or list of events (see examples above).

So my conclusion: Both kinds of information have to be stored in the database.
And there is no way around that. For both keep an important part of information about the real time.

…

B-4 revisited
Where do the different times apply to? What is their function?

Absolute time [A-1] has to be used for deciding at which time an article has to be public (when an article is shown or hidden), and for sorting, determines the sequence in which articles are presented, it will preserve the logical and historic order of articles and posts. Asolute time covers the relation between articles.
(This is what is working this way so far – the only problem is, that the absolute time is sometimes calculated falsely).

(Contextual) conventional time [A-2] has to be used for managing and presenting time-information (=“posted”). Conventional time covers the relation of articles to the users time (real time). So it has to be taken into account correctly during the input (for correct calculating the absolute timestamp for an article) and for outputting, when time should be presented in accordance to their context.

Last edited by saccade (2006-12-10 10:58:58)

saccade · 2006-12-11 00:40:36

As a summary here a schedule of txp’s handling of time now and how it should be:

The handling of time in txp is internally based on a normalized reference time (GMT) which is the same for all installations (it is saved im the timestamp).
Input and output of the time for an article/comment is driven by a conventional time which is the normal local time for the user/author (if he is within the same timezone).
the conventional time is defined by a timerule, which defines the difference to the reference time GMT.
In some areas the timerule is constant (e.g. GMT+1).
In other areas they change and thus are applicable only to certain times (e.g. in winter GMT+1 in summer GMT+2)
In the later case the conventional time has different distance to the reference GMT. Example: 10 a.m. german time is in winter 9 a.m. GMT, but in summer 8 a.m. GMT
but txp uses only one and the same timerule for every conventional time. The one rule in the settings, resulting from timezone and DST. Example: current german timerule: GMT+1
thus txp does calculate the reference time GMT incorrectly. Example: If today (11.12.2006) I set the timezone for an article to 1. January 2007, 10 a.m. and another for 1. July 2007, 10 a.m. txp will calculate for both a timestamp for 9 a.m. But this is incorrect. For 1. July 2007 german time it ought to be 8 a.m. GMT.
This doesn’t attract attention, as the used timerule is currently valid. Because in the output the error is corrected by using the same rule.
But as soon as the timerule changes, e.g. because summertime takes effect, the error is visible. Example: I change the timerule when summertime takes effect. It will then be GMT+2.
Because the timestamp is calculated incorrect, publication as well as shown time will be incorrect too and differ from the conventional time. Example: The article will correctly in accordance to the timestamp be published at 9 GMT. But 9 GMT in summer equals 11 german time. The time shown will as well be presented incorrectly as 11 a.m. german time.
Solutions:
When entering a time, the timestamp must be calculated using the correct rule, this means it must be determined which rule is in effect at the time of the timestamp in question.
For the current time this is easy it is the current rule (assuming it was set right)
But for a manual set time it must be determined, which timerule is in effect at that time. This must be done using a table, for DST are arbitrary.
That means a table with those rules for every timezone is needed.
For the output of time it is also necessary to determine which rule is/was/will be in effect and calculate adequate.
For this too a table is needed.
For deciding which article is published according to time=past/future the timestamp with its reference time is quite enough – provided it is correct fo revery time now.
Further thoughts:
For after 15+18 a table is needed, we could think about using this for the settings. So it could be reduced to setting the correct timezone. The DST-setting could be taken from the table, and DST could be activated automatically.
The table with DST-information for each timezone could be manages the same way as the lanuage files now: supported by the forum members, updated and maintained and from time to time actualized in the admin setting menu.
Some further plans and thoughts:
There is a little problem left: DST has two special effects, which need exceptional handling:
When changing from winter to summertime one hour is left. If an author places the left hour as a timestamp, it needs to be corrected to be one hour later. Example: 2.30 am doesn’t exist. It’s after change really 3.30 am.
When changing from summer to wintertime, one hour is duplicated: 2.30 in the summertime and again one hour later after the change 2.30 in wintertime. If a future article should be posted 2.30 the author must specify which of the 2.30 is intended. In this case the author should be able to select which timerule is used. Otherwise if an article is posted at 2.30 summertime, and another article at 2.30 wintertime the two different timerules should be visible as well. In Germany it should be shown as 2.30A and 2.30B.
So it is to be thought about, if it is better to apply timerule-tags to times/timestamps. This could be done with a selection and in output with the abbreviations.
If those timerules tags are added generally, then it would be possible to give the author/user a choice which timerule should be taken as the startpoint for input and calculation the internal timestamp (this way someone could use the different zones if he is on a journey).
For the output it could then be thought about, if the authors/users choice of timerule is passed over and used for calculating and presenting the articles time – or if all articles should be presented using a single timerule for all.
Even if you don’t want to give the users/auhors a choice of the timerule it is an advantage to save the original timerule: If you change the servers location and want to change the local time too, you have still information about the original timerule of existing articles. You could take this into account by presenting all old articles with their oroginal conventional time, and at the same time all new articles with the current time.

Last edited by saccade (2006-12-11 00:46:21)

saccade · 2006-12-13 11:37:40

Another correction needed. Sorry. Time’s a complicated materia.

By investigating some more steps how to deal with the timestamp, I came to the result, that I didn’t understand txps timestamp correctly.
For my server is running on GMT I thought GMT would be taken for the timestamp.
But this doesn’t seem to be true.
Instead it is the servertime, which is taken. And thus it’s also a relative/conventional time.
But it isn’t taken as it is, but modified by both: GMT and txp-internal-settings.

So the whole problem is based on the way, how servertime fits to the conventional time:

If it is given in compliance with conventional time (local time inkl. current DST-value) and txps time-settings too, then I suppose no error will be at all. This is the case if servertime = local time and if server time has the same DST-period as local time.
If servertime is different from local time in using DST (either by ignoring DST, e.g. a server that always has GMT – or by supplying DST in a different period), then there will be miscalculations.

Now I will again think about it and later correct above posts at the relevant parts (you will see the modifications).

At least I’ve found a way to keep the different aspects and requests apart, which I will post later after thinking over it again once more.

Textpattern CMS

Textpattern CMS support forum

#37 2006-05-10 06:18:44

Re: [issue] Daylight Saving

#38 2006-12-07 21:15:52

Re: [issue] Daylight Saving

A What is time?

#39 2006-12-07 21:20:12

Re: [issue] Daylight Saving

B Now let’s come to textpatterns time management:

#40 2006-12-07 21:21:39

Re: [issue] Daylight Saving

#41 2006-12-07 21:39:13

Re: [issue] Daylight Saving

Some handling thoughts for the change:

#42 2006-12-10 00:55:23

Re: [issue] Daylight Saving

#43 2006-12-11 00:40:36

Re: [issue] Daylight Saving

#44 2006-12-13 11:37:40

Re: [issue] Daylight Saving

Board footer