Tags:
archive_me1Add my vote for this tag create new tag
view all tags

Always see local server time, everywhere, never anything else

Some people have this specific requirement, e.g. on company intranets that are not international.

Some people are unable to implement TWiki in their work environment unless it shows only "the real time!", i.e., local time, everywhere.

This becomes especially important where TWiki is being used for time-critical entries such as logs and incident reports. It would also assist gaining buy-in where closed user populations have little contact with the rest of the globe and are not accustomed to mental time zone conversions.

For most places, and for public use, it is a bad idea to pin displayed times to one particular location, and I strongly advise the default GMT/UTC in all cases except the ones outlined above.

amended Specification for inclusion into Cairo

this change adds %DISPLAYTIME{}% for those places (like templates and search) where we want the displayed time to be configurable. To set what timezone you want displayed there is a TWikiCfg variable

#display Time in the following timezones
# gmtime / servertime
#TODO: would like an over-ride mechanims (plugin?)
$displayTimeValues   = "gmtime";

at a later date we should also add a PluginHook to allow the SessionPlugins to over-ride that setting on a per-user (or user's TZ) basis.

Note:

  1. All internal times are still in GMT
  2. All Displayed times are configurable as either gmtime (default) or servertime
  3. %GMTIME{}% & %SERVERTIME{}% remain the same as they allow you to specify those times

Implementation details

  • added a new function formatDisplayTime that calls formatGmTime and formatLocTime..
  • added a %DISPLAYTIME% for the template handling.
there is now some possible duplication between handleTime, formatGmTime and formatLocTime

Comments for inclusion in Cairo

As my work also wants the display to be AlwaysServerTimeZone, I have modified SueBlake's patch to be configurable (it was very simple) and would now like to commit it into Cairo....

-- SvenDowideit - 06 Jan 2004

For the variable name, how about %SHOWTIME{}%, yes it's show time (just kidding smile ). How about calling the variable %LOCALTIME{}%, this is in anticipation of a future version to ShowLocalTimeOfUser.

-- PeterThoeny - 06 Jan 2004

Ok, I have not written the spec yet smile (later - dinner first) - i only wrote the quick note so others (including you) could tell me what you thought. I don't like %LOCALTIME{}% as much as that implies that it should be for displaying the local time. What I have done is make DISPLAYTIME change depeinding on a Setting, so by default we would display GMT Time, but you can set it to show SERVERTIME. later we can extent it to allow it to display LOCALTIME (local to the user). but irrespective of the setting, the templates and the code would say %DISPLAYTIME%

-- SvenDowideit - 06 Jan 2004

And for me it is time to get some sleep at 01:30am local time.

I see the $displayTimeValues in TWiki.cfg just as a temporary hack until we have ShowLocalTimeOfUser in place. At that time it does not make sense to switch the display between servertime, gmt and localtime. Or may be there is a use for it?

  • no - we need to have a displayTime setting for those twiki installations that do not have / don not want sessions / user preferences. when ShowLocalTimeOfUser is implemented I see this as a third option for the setting..

For the patch, watch out that you do not make the server time changes in too many places, the RCS times for ci/co/repRev need special attention.

  • Yep - seems to be ok - SD

-- PeterThoeny - 06 Jan 2004 -- SvenDowideit - 07 Jan 2004


AlwaysServerTimeZone Patch (kept for BeijingRelease Users)

After long discussions in SettingCorrectTimeZone, several people tried patching TWiki in different ways, often without total success. The changes required are more complex than expected, spanning multiple files. RichardLewis came up with a set of changes to the 2001 version which finally seemed to work for him on Linux (good on ya Richard!), but there was little mention after that. Did anyone else try? Who knows.

I've taken Richard's changes and applied them to Beijing as best I could, and produced a single patch that changes several files in the TWiki file tree. So far it seems to work for me (on FreeBSD) but I haven't been able to give it a lot of testing. I would love some more people to try it and provide feedback here. Maybe improvements.

If it works out OK, maybe we can offer it as a... well it's not really a plugin or an addon, but it is an optional feature that some new TWiki tryers would need before TWiki could be accepted on their intranet.

How to use

  1. Download the attached patch
  2. Do a fresh test install of Beijing TWiki, or back up well and cross fingers hard
  3. Change directory to the directory which contains twiki as a subdirectory.
  4. As root, use the following command to apply the patch to many files at once:
   patch < /path/to/the/twikipatchfilename
Scroll back through output to check that everything applied OK.

Don't confuse with...

Some people have a very different need. They want time zones that change to suit each user's location, or different office locations. While their needs are just as valid as mine, they are quite different and the solutions are probably mutually exclusive. This patch isn't meant to take any steps in that particular direction, sorry folks.

-- SueBlake - 27 Jul 2003


Feedback on Patch

Thank you for your efforts! I applied your patch (please verify output below). Time display has been changed, but I still can't make it correct - my server's TZ is MSD (which is GMT+3), and instead of 12:54 I see 05:54. I can't figure out why. Without the patch it showed 08:54 smile

Meanwhile I noticed that in diff display it still shows GMT suffix.

Here is the patch command output:

[web@filesrvr2 httpd]$ patch -p0 < AlwaysServerTimeZonePatch.txt 
patching file twiki/bin/changes
Hunk #1 succeeded at 81 (offset 1 line).
patching file twiki/bin/mailnotify
patching file twiki/bin/view
patching file twiki/lib/TWiki/Attach.pm
patching file twiki/lib/TWiki/Store.pm
patching file twiki/lib/TWiki.pm
Hunk #1 succeeded at 1003 (offset 10 lines).
patching file twiki/templates/changes.tmpl
patching file twiki/templates/mailnotify.tmpl
patching file twiki/templates/search.tmpl



Hunk #1 succeeded at 20 with fuzz 2.
patching file twiki/templates/searchbookview.tmpl
Hunk #1 succeeded at 20 with fuzz 2.
patching file twiki/templates/searchrenameview.tmpl
Hunk #1 succeeded at 23 with fuzz 2.

-- DmitryDiskin - 28 Jul 2003

Sue - thanks for the patch and for following the PatchGuidelines! If you could make this configurable, i.e. define a variable $useServerTime in TWiki.cfg, defaulting to 0, that would make it possible to get this into the core without causing backwards compatibility issues. I haven't tested this so it might need some more work in detailed areas - for example, it would be nicer to see some code sharing between formatGmTime and formatLocTime since they are very similar.

BTW ImplementationDate refers to when a feature makes it into a release - a bit confusing, see CodevFields for discussion.

-- RichardDonkin - 28 Jul 2003

Thanks for fixing the form, Richard. I was confused about all three fields and hoped someone would come along and make it right smile

RichardLewis is the brains behind this, I've just done the packaging and PR. I'm sure he'd be delighted if someone improved on his ideas. I don't hack perl myself, but patches are easy to make when given the code changes on a platter.

Selfishly, I'd love to see something like this in my next default TWiki, but it's not what everyone wants and I'd hate to have, for example, local USA times imposed on me when I visit public TWikis. GMT is the only sensible default. Some of us simply need other options before we can get it approved inside our workplace's (cultural) firewall.

Dmitry, thanks for trying it out! Your time changes are indeed peculiar. Let's start from the bottom, for the benefit of anyone looking on. Is your (unix) computer set to GMT and your operating system set to your local time zone, as it is usually done?

Try putting the following text into a topic, except use percent signs where I have slashes. See if it displays what you expect. If convenient, try it (a) without this time patch applied, and (b) with the patch. (I have two twiki trees and carefully 'mv twiki twikipatched; mv twikidefault twiki')

Local time is /SERVERTIME/ and gmt is /GMTIME/ according to TWiki.

(e.g. at twiki.org it is 2024-02-06 - 01:13 and 2024-02-06 - 09:13 )

Compare with what you get on the commandline. For BSD-like systems with a bourne/bash style shell, you can do this

$ date
$ TZ=GMT date     # or just   TZ=  date
Those two times should be the same as what the test line above displayed, and the same as what you expected. If all of that checks out, we can start pointing fingers at the patch.

-- SueBlake - 28 Jul 2003

Me again. Dmitry, whoah! Your patch output looks wrong. The line numbers are all different. The general format of your patch program is not the same as mine, so I can't easily compare everything. Are you using the February 2003 TWiki that the patches are written for?

-- SueBlake - 28 Jul 2003

[...stuff moved to TimeFormat...]

Ummm, what is the SERVERTIME variable listed in TWikiVariables? Where does it's value come from? I've searched all through twiki.org for a description of this variable but have come up empty handed. There is a topic for GMTimeVariable, but not a corresponding one for ServerTimeVariable.

On all of the twiki's I have running (cygwin, linux, netbsd) SERVERTIME is exactly the same as GMTIME.

Trying this patch on the cygwin machine did not yield the anticipated results, very similar to DmitryDiskin's report.

-- MattWilkie - 28 Jul 2003

Well, I'm going to try your suggestions (sorry for late response, it's timezones issue :))

Looks like our HW clock is set to our TZ, not to GMT:

[web@filesrvr2 httpd]$ date
Tue Jul 29 10:42:34 MSD 2003
[web@filesrvr2 httpd]$ TZ=GMT date
Tue Jul 29 06:42:36 GMT 2003
[web@filesrvr2 httpd]$ hwclock
Tue Jul 29 10:42:28 2003  0.381728 seconds

Both patched and unpatched TWiki said this:

Local time is Tue Jul 29 03:41:48 2003 and gmt is Tue Jul 29 06:41:48 2003 according to TWiki.

Why do you think that the patch was wrongly applied? I suppose it seeks for similar lines (using context) and makes correct replaces. Am I wrong here?

-- DmitryDiskin - 29 Jul 2003

[...snipped to FimeFormat...]

To Sue/Dmitry - I think Dmitry is right, patch is context-based rather than purely line number based, but of course there might be some reason why the patch doesn't work on the code he is using. It would be advisable to just use the 01 Feb 2003 release as a base, or ideally TWikiAlphaRelease to make sure it's easy to get it into CVS.

As for making this configurable, how about using %TIME% in the templates and the code, and making the $useServerTime flag in TWiki.cfg control whether this expands to GMT or local time? This would mean that templates could just use %TIME% everywhere and allow use of the correct local or GMT time as needed - this would also be forward compatible to per-user timezones in the future, i.e. %TIME% would map to the user's timezone when that logic is eventually added (might even be possible to override this in a plugin).

-- RichardDonkin - 29 Jul 2003

Patch problem: Some little bits of GMT are oozing back in. It needs another patch.

When I edit a topic, my signature for pasting still has GMT date, i.e., if it's morning when I edit then the date given is yesterday. A similar thing happens when I have the %DATE% variable in a template topic, it comes out in the topic as yesterday's weekday and date (GMT).

Leading question: So where does this DATE variable come from? I couldn't find it mentioned in the docs.

Following question: What can I use instead of DATE in (a) edit.tmpl (b) a template topic? I tried using %SERVERTIME% in a template topic and it only spat out the variable itself.

Patch Note: I think this patch won't work unless you run unix and your computer is set to GMT and your operating system is set to your local timezone.

Time Discussion: Like I said, personally I don't give a flea's moustache about user times smile and I cannot afford the luxury of being distracted and waiting for years until some GrandKitchenSink time plan is implemented to please everyone's nice-to-haves. I just need reliable server time, it is mission-critical to our organisation. I've waited two years and I have to have it NOW or ditch all thought of TWiki for intranet use. Some new TWiki admins have already thrown in the towell because of intranet time requirements and I hope we are near to a good solution for this. It feels more like a bugfix than a feature when you're in my shoes.

I think it is crucial to separate these two very different requests in time discussions, this topic and the usertime idea, because everyone gets confused and grows the plan and it'll take another two years to get some megaresult and we'll all be gone then. Sure, make the two ideas compatible if you can, but don't muddle them and don't slow me down I can't wait.

The big issue is that some of us cannot use TWiki at all unless it supports one, single, solitary, always the same, time zone in our organisation, everywhere, including in TWiki. We are born, live, work, and die in that time zone, we can drive two days and nights without stopping and not leave it, we have large national corporate intranets, and we hoped that TWiki would be valid for this setting because we believe that TWikiMission speaks to us.

Please help me get something together that people in this situation can use real soon now before they all run away, and I'll do whatever I can to help build a kitchen sink version later if that's what people want.

-- SueBlake - 04 Aug 2003

meta: moved ideas about user time to TimeFormat since it was getting in the way. Please re-read your writing to make sure I haven't inadvertantly changed the meaning or moved the wrong idea. The pre-edit page is revision 1.15 This meta-note can be deleted when everybody has reviewed and corrected the edits.

Sue, I hope this clearing of the decks helps you quickly get what you need.

-- MattWilkie - 04 Aug 2003

(Comment of mine re-instated since this isn't going to make it in the core unless it can be configured in TWiki.cfg)

As for making this configurable, how about using %TIME% in the templates and the code, and making the $useServerTime flag in TWiki.cfg control whether this expands to GMT or local time? This would mean that templates could just use %TIME% everywhere and allow use of the correct local or GMT time as needed - this would also be forward compatible to per-user timezones in the future, i.e. %TIME% would map to the user's timezone when that logic is eventually added (might even be possible to override this in a plugin).

-- RichardDonkin - 04 Aug 2003

Thanks Matt.

Richard, that makes good sense. Now that my head has cleared I understand what you are suggesting and recognise it as exactly what I expected to find in TWiki when I first ran it up, a toggle in the configuration. It would be wonderful, flexible for coders and admins, and follow the POLA for people trying out TWiki for the first time. If people don't like the option being available (and I still support arguments for GMT on public sites) it could be slightly obscured like a few things already are.

Aside from the fact that I can't code this improvement myself, I'm wondering if it would work across various operating systems and CMOS time setting habits, or would it be specific to standard unix systems with their GMT base time and local TZ setting.

-- SueBlake - 04 Aug 2003

Is there anyone else out there willing to code in the configurability and generally work on this patch? If so, I'm prepared to get it into the core but I don't have a lot of coding time at present... Not sure what POL means - piece of luck, path of life smile ?

The code should be done in a portable way to work across Unix and Windows - for Unix/Linux, I think it's reasonable to use the GMT base time model, but in fact the only requirement is that the relevant Perl functions (e.g. localtime or strftime) return the desired local time. The actual CMOS/hwclock settings don't really matter as long as local time is correct.

-- RichardDonkin - 05 Aug 2003

Urk... I plead typo! It was supposed to be POLA (principle of least astonishment) but the A fell on the floor.

I agree, portability is important. Times like this I wish I knew how to code stuff myself. TWiki would be so rewarding to play with for someone with a few skills in that area. I understand the bits that read like plain English sentences, but I'm still flummoxed by this %DATE% thing, I've spent the last day doing recursive greps and can't find where on earth it is defined. It looks like that's the key to my current time hack for work. Should I ask about it in the Support web, go to a perl group, or sit here and wait for a kindly pointed finger?

-- SueBlake - 05 Aug 2003

I was thinking: if "last updated" is more than a day ago, I mostly do not care about the exact time. So maybe if we have a way to display (35 munutes ago) or (2 1/2 hrs ago)) if page was changed recently (today), and just date without time if was changed long time ago, and we can get rid of server time issue completely.

Does it make sense? What else I forgot about?

-- PeterMasiar - 12 Aug 2003

Sue,

To fix the %DATE% thing look in bin/edit for the line my $foo = &TWiki::getGmDate(); Replace that with my $foo = &TWiki::getLocalDate(); Actually I am not sure if that actually fixes anything .. here is what fixed mine:

In lib/TWiki.pm you will want to replace

$_[0] =~ s/%DATE%/&getGmDate()/ge; # deprecated, but used in signatures

with

$_[0] =~ s/%DATE%/&getLocalDate()/ge; # deprecated, but used in signatures

Also in lib/TWiki.pm search for sub getLocaldate and change that to sub getLocalDate , or just use the lower case d in the above fix, whatever you do, be consistent.

-- KyleGossman - 13 Aug 2003

Peter, that might be fine for a chatty TWiki. I'm using it to log system outages, repairs, security issues, etc. We need evidence that someone made the report at a particular time to demonstrate service levels met and occasionally it supports an overtime claim.

Also, throughout the morning GMT shows yesterday, so it's a date thing not just time, and half a day's work goes into the reports for the wrong month. Users might read the wrong time stamp on an outage notice and complain that it took 11 hours to notify them, or worse, re-enter a morning's work when they did't have to. The possible consequences of not having the correct date and time are too hideous to risk.

Kyle, thanks for the info! I'll try it out in a few days when my head clears (flu).

-- SueBlake - 13 Aug 2003

This topic is marked as FetureDone but has 0% DocProgress. Is there any documentation required? If not should it be set to 100% even though there is no documentation required (beyond this topic) for the sake of the totals in the totals in CairoRelease?

  • yeo - thankyou Sam smile -- SD
-- SamHasler - 21 Apr 2004

new idea moved to another topic SetTimezoneInTWikiDotCfg


Category: TWikiPatches

Topic attachments
I Attachment History Action Size Date Who Comment
Texttxt ASTZPatchOutput.txt r1 manage 4.7 K 2003-07-29 - 20:58 UnknownUser Sue's output applying patch
Texttxt AlwaysServerTimeZonePatch.txt r1 manage 7.7 K 2003-07-27 - 05:44 UnknownUser Patch TWiki tree to display servertime everywhere
Edit | Attach | Watch | Print version | History: r35 < r34 < r33 < r32 < r31 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r35 - 2004-07-21 - SvenDowideit
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.