The feature I would like to have changed the most is the way the time is handled in TWiki.

Instead of using the date/time format of "29 Oct 2001", it is in my interest to use my company's standard of "2001-10-29T21:59Z" (meaning October 29, 2001 21:59 UTC)

Going through the code trying to find the 1 place to change this failed because there are too many functions scattered that handles the time.

My idea, if it's not already done, is to have a two variables to handle the times. A variable to hold the timezone, and one that will hold the formatting. The time would be converted on the fly to match the timezone variable (only if it's different than the machines timezone).

I believe you should always use the numeric representation of the date in RCS, etc, but the time format should be user configurable.

I have made the changes in the code, but this makes it nearly impossible to upgrade later. (Trust me. The upgrade to the Sept2001 wasn't easy at all.)

Any suggestions/comments?

-- JustinHickman - 29 Oct 2001

Totally agree with you. The timezone variable have to be user-configurable, I think.

-- JikhanJung - 31 Oct 2001

It would be nice if the timezone for the display of times would be configurable.

-- MichaelUtech - 14 Nov 2001 (refactored from Topic SeveralIdeas by MartinCleaver - 17 Nov 2001)

You can change the Time Zone representation for everyone on a given system using by following the instructions in SettingCorrectTimeZone.

As for future implementations, it's probably a good idea to read the preferences from the user's page since the server time might not be in the same time zone as all of its users.

What about having a variable in the user page, say, GMTOFFSET where the user could put his or her time zone offset from GMT (e.g. +5, -5). We'd have to remember to account for time zones that have half hour offsets -- Newfoundland immediately comes to mind, but I'm sure there are others.

This could be calculated in the view script.

-- CoreyFruitman - 22 Mar 2002

On a default TWiki installation (such as TWiki.org) the user is only known during edits and similar calls, so users preferences can not be used. If you use the SessionPlugin or similar then after a user does an edit they are remembered and hence their preferences can be read.

-- JohnTalintyre - 22 Mar 2002

Good point. Maybe a better solution would be to use JavaScript's getTimeZoneOffset() and let the browser calculate the time to display. Obviously this would only work if users set the time zone on their PC.

-- CoreyFruitman - 25 Mar 2002

Using JavaScript would be fine, as long as it has a decent default in case JavaScript is unavailable or turned off for some reason. Also, I'd like to suggest that Twiki use one of the many Date/Time modules available on CPAN for date calculations and formatting, rather than doing it by scratch. My personal favorite is Time::Piece, but most or all of the CPAN modules have already solved the problems related to dates and times, and have been thoroughly tested in a wide variety of settings. Why should Twiki reinvent that particular wheel?

-- WesleySheldahl - 15 May 2002

When I first hit this problem (I just set up my first TWiki yesterday), I tried a localtime hack like the one on SettingCorrectTimeZone, and was surprised that it didn't work. I even tried setting $ENV{'TZ'} manually above the localtime call, but no dice. Shrugging my shoulders I did this instead:

sub formatGmTime
{
    my( $theTime, $theFormat ) = @_;

#    my( $sec, $min, $hour, $mday, $mon, $year ) = gmtime( $theTime );
    use Date::Calc qw/Add_Delta_DHMS/;
    my( $sec, $min, $hour, $mday, $mon, $year ) = reverse Add_Delta_DHMS(reverse((gmtime $theTime)[0..5]),0,-7,0,0);

which seems to work approximately correctly for me on the west coast, although it will break when the daylight savings changes again Shouldn't be too difficult to get the logic fully correct, though.

For what it's worth, I strongly support the idea that the "timezone to use for presenting dates" should be an optional web and user-level preference. Always store in GMT, and always give the user the ability to display it in their preferred form at runtime.

-- JaredRhine - 18 Jul 2002

---

next bit moved here from AlwaysServerTimeZone by MattWilkie - 04 Aug 2003

Looking at this patch [AlwaysServerTimeZone] makes me wonder how hard it would be to make it work for any offset. Anyone tried it? That useServerTime could then be replaced with gmtOffset variable.

-- MartinCleaver - 28 Jul 2003

This already works for any offset, that's what local time means - just set the appropriate TZ as needed outside TWiki and it should just work. Doing a naive 'gmtOffset' is a really bad idea - timezones are very hard to get right (see the experience of Unix people over the decades), given the issue of DST kicking in at different dates around the world, half-hour/quarter-hour offsets, and so on. Much better to use the OS's version of local time, which is likely to be correct.

In fact, if you have working POSIX locales you can also use the Perl POSIX module to render the local time using the required date/time format, although in my experience of I18N, locales are frequently broken. Anyway, that's another problem, InternationalisationDateTimeDisplay, as part of InternationalisationEnhancements.

There's some more discussion of this generally, including some strftime coverage and some great articles, at Support.TimeZone - I'd recommend reading some of the articles as they are very informative.

-- RichardDonkin - 28 Jul 2003

This would have other broad reaching effects, but what if one could use math on variables? What if we could just do this in TWikiPreferences:

      * Set SERVERTIME = (%GMTIME% - 8)

and users do this in their user page:

      * Set MYTIME = (%GMTIME% + 5)

TWiki would continue to use GMTIME throughout, revision dates and such, and skins would use whichever variable best suited that site or user.

(and I'd still like to know where the already existing servertime variable gets its data from)

-- MattWilkie - 29 Jul 2003

Matt - you need to go down the same road I did. Following Richard's TimeZone pointer, the most enlighting (so to speak) article about the real weirdness in daylight savings time and how it messes up the idea of timezones as an offset from GMT is: http://webexhibits.org/daylightsaving/f.html

But, what other broad-ranging effects were you concerned about?

if math-in-variables becomes a feature there is potential for people to screw up system preferences which have nothing to do with the example here. -MHW

-- MartinCleaver - 29 Jul 2003

Thankyou, Richard, for the pointer to the articles on why timezones are complicated - never again will I suggest that it should just be an offset!

Got me thinking though - could we just set $ENV{TZ} = %TZ% for each user?

-- MartinCleaver - 29 Jul 2003

No problem, many people have made that mistake and I just wanted to nip it in the bud... Some sort of per-user timezone setting would be nice, but that would require the SmartSessionPlugin or similar of course. Once we have a global server timezone setting (with AlwaysServerTimeZone) we can look at doing per-user settings for timezone, locale/language, skin, and other nice things, as a second phase.

[...]

-- RichardDonkin - 29 Jul 2003

---