Feature Proposal: Use ISO 8601 Dates

Motivation

The current default date format used in TWiki is only good for English language TWikis. Originally it was proposed to use ISO 8601 date format for non-ambiguous date display. This modified proposal suggests adding a small selection of formats to choose from.

Description

Different languages use different date formats. Some are ambiguous. What is 03/04/05? It depends. In the USA it is 04 Mar 2005, in Japan it is 05 Apr 2003, and in Germany it is or 03 Apr 2005.

TWiki currently uses the format 25 Oct 2005 for signatures, topic timestamps and creation date. This date format is commonly used in the internet (in e-mail headers etc). It is crisp, but has some issues:

• Not sortable
• English language specific
• Longer than necessary

There is an standard for dates, ISO 8601. Examples:

• Date: YYYY-MM-DD, e.g. 2003-04-05
• Date & time: YYYY-MM-DD hh:mm:ss, e.g 2003-04-05 16:30

Suggestion

A new $TWiki::cfg{DefaultDateFormat} is added to configure (right after $TWiki::cfg{DisplayTimeValues}) with the current format as default '$day $month $year'. This variable will additionally have at least "$year-$mo-$day". We could make it flexible but if we do, only a few formats will be fully supported by the internal sorting routines. A small selection of formats is available: $day $month $year, $year-$mo-$day, $year/$mo/$day, $year.$mo.$day.

Per default this {DefaultDateFormat} is set to "$day $month $year", it can be changed to one of the others three formats.

By design, formats like $day $mo $year or $day/$mo/$year or $mo/$day/$year or $mo.$day.$year or $mo-$day-$year or anything like this is excluded; this is to avoid confusion. Most TWikis are in some sort of international environment and especially Americans cannot understand that the rest of the world sees 9/11 as 9th of November. The web knows no borders. We only offer formats that can be understood by all.

Code impact

This requires code changes 2-4 places replacing the hard coded "$day $month $year" by a config variable.

And it requires 3-4 additional simple lines of code in parseTime().

And a small addition in TWiki.spec

-- Contributors: PeterThoeny, KennethLavrsen - 2007-05-21

Discussion

We will loose readability. Someone who reads the date must know that the ISO standard is used, so ambiguity remains.

What do we gain? Sortable dates. The question is whether this should be something imposed on the UI. I can imagine a sorting mechanism that uses ISO dates under the hood, but displays in the old manner.

The other arguments:

• English language specific: this can be internationalized like we have done with other strings
• Longer than necessary: we gain 1 character!

-- ArthurClemens - 26 Oct 2005

Hm, I'm all for using ISO Dates all over but isn't THAT an incompatibility issue par excellence?

-- FranzJosefSilli - 26 Oct 2005

it does sound like a horrible hack to acheive something that the TopicObjectModel with date object should have more ability to address. of course when it comes to signatures, its stupid to have them at all - they should really be generated at view time - like using that clever plugin ContributorsPlugin that can thus get the info out of the versioning system....

-- SvenDowideit - 26 Oct 2005

This is related to the issue of 'what time to display?' Recall - when searches are geenrated or the tme of a lsat change is indicated it is 'server time' or 'GMT'. Many people have problems with this.

Its not insufferably difficult to make useof the TZ setting in the environment. Don't we already do that for 'server time'?

So really the change is to have a TZ setting in the user's home page that can over-ride that. Voila, we've set the time zone.

Now in Dakar we also have the ability to set the language in the user's home page. .... if, that is, we decide not to ask the browser ... its there in $ENV{'HTTP_ACCEPT_LANGUAGE'}.

I think there are a few very basic things we have to address using this:

• Recognise that the internal store needs to be computer friendly and the external representation needs to be human friendly.
  To a degree we do recognise that. Its the latter that is the 'friendly to whom?' that we are trying to deal with.
  • ISO isn't particularly human friendly
  • Worrying about extra charecters got us into the Y2K mess!
• Make the month and the year unabiguous.
  We have that already, but its very 'English Language'

In CPAN::Date::Format we have the strftime() function that has multi-lllangauge support. It seems a lot of code to do a simple job - more code bloat! - but then one realises that it also gives the user the ability to format the date in a custom manner:

• 26 Oct 2005
• 26th October, 2005
• October 26th, 2005
• 26/X/05 - month as Roman numeral

Sample code at http://cpan.uwinnipeg.ca/htdocs/TimeDate/Date/Format.html

-- AntonAylward - 26 Oct 2005

I added this suggestion based on feedback I got. It actually does not reflect my personal opinion. For the English speaking community, 15 Jan 2026 is much more readable than 2026-01-15. To me, as part of localization effort, a well defined ShowLocalTimeOfUser spec is a more generic solution. TWiki is a platform, like an OS. As such it should handle date display appropriately.

As for CPAN dependency, we need to try to reduce the number of modules needed. In fact, because of performance reasons, the SpreadSheetPlugin does not rely on a CPAN module and does its own date calculation. This performace gain is nullified with the many CPAN modules that are now needed in DakarRelease.

-- PeterThoeny - 26 Oct 2005

Perhaps you should extract some of those date & time functions such as _date2serial() and put them in TWiki::Func them plugins such as UserInfoPlugin can use them instead of Date::Parse::str2time and we can drop the use of a another bloated CPAN module.

Or, more generically, we need someone who can go though the modules looking for things like that which can be factored out.

-- AntonAylward - 26 Oct 2005

If you are seriously considering optimizing by extracting code from CPAN modules, please do so using a script, and a MANIFEST like system, so that updates can be done automatically - otherwise you're creating a huge steaming pile of unmaintained code that will add a huge burden to those poor buggers that are maintining TWiki.

While you're suggesting things like this though, please consider the reasons that code re-use exists...

-- SvenDowideit - 27 Oct 2005

Date formats should be localised at the site level, in my view - each country has a preferred date format, although Scandinavia has something close to ISO 8601, I don't think we should impose that on everyone. Now we have session-based user authentication in DakarRelease, it would be best to address two issues at once:

1. Use localised (non-English) date formats that make sense to the user - e.g. 28 Okt 2005 in Germany or the Japanese date format (which doesn't use any Roman letters)
2. Display time in the user's local timezone - see TimeZone for frequent complaints.

These would both align with the TWikiMission since many corporate users of TWiki have users in several timezones, and demand for internationalised support in TWiki is growing (see UserInterfaceLocalisation). Although the locale could specify a time format (e.g. fr_CA for French speaking Canada, en_CA for English speaking Canada, and dk_DK for Denmark), it's not granular enough to specify a timezone.

Also, see TimeFormat and in particular TimeZone for discussion about how to do timezones - it really is best to re-use existing date/time CPAN modules, which are complex for a reason. The TimeZone page has links to good articles about why you should never write your own timezone code

Although the CPAN:POSIX module, which is already loaded by I18N TWiki sites, already includes strftime, the brokenness of Perl locales on Windows and many other platforms makes it a bad idea to use POSIX.pm's strftime.

-- RichardDonkin - 28 Oct 2005

Some time has passed since we had this discussion. With more feedback via e-mail I am coming to the conclusion that we should do the right thing and move TWiki more towards an internationalized product.

Lets do that one step at a time. I suggest we do this:

• Step 1 (this proposal topic): change the default date display to the ISO format as outlined in the proposal above (in signatures, topic revision date, topic creation date, WebChanges and all other standard topic reports).
• Step 2: Introduce a local time display, set per user; similar spec to local time setup/preference of operating systems (feature discussed in other topics, such as ShowLocalTimeOfUser, SetTimezoneInTWikiDotCfg, ViewInClientTime, RefactorTimeHandling)

-- PeterThoeny - 31 Mar 2007

I'm not too keen on having ISO dates as the default format - they aren't particularly user friendly for people speaking English, and are not the native format used in most countries either, so almost everyone would have to use an unfamiliar date format, unlike almost every operating system's approach to date formats, which is to use either English or localised date format. The W3C FAQ on date I18N agrees with this view, and of course TWiki can process dates internally in UTC for sorting, just like Unix.

So I would prefer if ISO date format is a configurable option. In fact, the local date/time display should be configurable site-wide in step 1 so that server time or default local time (e.g. for single site installations) can be set to something sensible - then you can at least use a localised date format, of which ISO date is simply another one. This also avoids the backward compatibility issues - would you convert existing comments from English format to ISO?

Agree with Step 2 - now that TWiki has proper session support this is not too hard to do. However, like I18N, I expect there's a lot of very detailed work and it needs to be done right using good CPAN modules, to avoid breakage in corner cases (e.g. half-hour timezones as in parts of Australia). This could be a performance hit of course, so it should be optional as with I18N (the hit is probably much higher than just enabling I18N regexes and locales, more like UserInterfaceInternationalisation), and ModPerl or similar may be needed.

Two key articles to read:

• Article on how Movable Type weblog handles dates and times - CPAN modules are far superior to writing your own code
• Perl.com article on date/time handling - good overview of CPAN modules, also recommends CPAN:TimeDate as fairly quick and lightweight
  • This review of TimeDate also says it's "not too slow"

Since we already load CPAN:POSIX for I18N, we might get better performance if we first use that (based on user's locale in step 2), and (configurably) fall back to another module for localised and local-time dates on systems with broken locales and to support corner cases - so that only Windows users and people in "odd places" pay a performance penalty. This also avoids the issue that CPAN::TimeDate supports only a short list languages, e.g. not Japanese. Overall I think this is the best compromise, as the POSIX::strftime routine gives you localised (I18N) dates for free, and also supports timezone settings. The Phase 2 could be to do TimeDate, as long as we have pulled all date-time processing into a single set of routines.

See TimeZone where I provide some Perl one-liners using POSIX::strftime to show how this works. Another bonus is that the POSIX module is part of Perl core modules, so most localised date users would not need to install a new module. Actually a better script to demo this is here:

export TZ=CET-1CST                      # Really should set timezone for each test, but works with locale and/or TZ settings
export LANG=de_DE.ISO-8859-1
perl -we 'use POSIX; @a= localtime; print strftime "Date %x - time is %X %Z\n", @a'

export LANG=ru_RU.KOI8-R
perl -we 'use POSIX; @a= localtime; print strftime "Date %x - time is %X %Z\n", @a'

export LANG=ja_JP.EUC-JP
perl -we 'use POSIX; @a= localtime; print strftime "Date %x  - time is %X %Z\n", @a'

-- RichardDonkin - 01 Apr 2007

If using a certain CPAN lib is a performance hit - why does it then becomes acceptable anyway if it is configurable?

Isn't that the same as saying: "if it does not hurt the English speaking then it is OK to slow TWiki down for everyone else".

I do not mind that our date handling becomes more international. But it must be with effective code that does not slow down TWiki further no matter where you are from.

-- KennethLavrsen - 01 Apr 2007

Here's how it would work IMO re different locales and performance:

1. Use CPAN:POSIX strftime to do local-time and localised-format output of dates & times - primary mechanism, should be reasonably fast, already loaded by I18N sites
2. As configurable fallback, use something like CPAN:TimeDate - this is mostly for sites with broken locales, primarily Windows where not using TWikiVMDebianStable, because that means POSIX::strftime will not work.

There might be a better Windows option using CPAN:Win32::Locale or other Win32 modules on Windows, but currently non-TWiki VM users with I18N requirements on Windows might have less performance (but I've not tested this), depending on the cost of loading and using CPAN:TimeDate.

There's no simple way round this without using CPAN modules, and most of the date-time modules seem to have poor I18N of date-time formats - App::datetime has a summary of some key modules including comments on I18N support.

-- RichardDonkin - 02 Apr 2007

A little more thinking on this:

1. For ISO dates, it's easy to use strftime or another module to generate them, e.g. if there's a config optional called {UseISODates} set. Localised dates are the hard part.
2. Dates for use in signatures could be localised or site-standard - latter is preferable for consistent sigs across a site, but former is better for large sites where each web may have users in a different country.

I would probably make signature date format a user-level config option as it's somewhat site and user specific - could also let users specify their own format using day, month, year via strftime options (but beware that some strftime options are operating system specific).

Also, some date-time formats require specific fonts to be installed, like Japanese one used on this comment.

-- RichardDonkin - 2007年4月3日

Signatures today are static text once created. On a multilingual site - why would a French users Polish spelled Month in a signature help a French speaking viewer? The multilingual TWiki will not translate all the text inside the topics to different languages. I never understood the idea of a multilingual TWiki. I understand that a smal Danish company will want a fully Danish TWiki. They write in Danish. They want a UI in Danish. And the signatures in Danish. But I totally fail to see signatures as multilingual. What needs to be multilingual is the dynamic dates as displayed by the TWiki engine. Like the timestamps in searches and upper right corner.

International companies that uses a TWiki accross borders probably choose a common language and stick with that.

The obvious advantage of the 2007 04 08 format is that it contains no language part. 04/08 2007 means 4th of August in Danish. I will personally verbally pull the head off a person that ever suggests that format for anything in TWiki no matter if it is mm/dd or dd/mm. I have seen so many mistakes in real business life because if this diffference. The current 08 Apr 2007 is at least unique but not very international if you are not English speaking or working in an international company where English is the company language.

-- KennethLavrsen - 08 Apr 2007

This conversation is going way beyond the proposed change. I invite all to read the original proposal again and to give feedback on that proposal alone. Specifically, a per user localized time display is out of scope of this proposal. Lets do one step at a time. Changing the default time display to 2026-01-15 does not prevent a localized time display as a later enhancement.

TWiki is used by the majority of fortune 500 companies. Why not do the right thing for multinational companies?

-- PeterThoeny - 2007-04-08

Some Wikipedia content is also converted to ISO date format, as can be seen in a recent example.

-- PeterThoeny - 09 Apr 2007

I don't think ISO dates should be the default, hence my suggestion that dates should be configurable, defaulting to local time and localised format. This allows those who want to use ISO dates to do this, either per-user or per-site, but I don't think we should be mandating this - see the W3C I18N FAQ above which has some good arguments against ISO dates as a localised format.

Just to be really clear, ISO dates are not a good solution to the issue of date I18N and localisation - they are the local date format in a very few countries. They can be a good solution to some multinational organisations that have standardised on ISO dates, which is fine, but should not be the TWiki default.

I would agree that most sites would use a single language, but some communities do use multiple languages, sometimes per web. The signatures would normally match the language/locale for the site (or web).

-- RichardDonkin - 14 Apr 2007

I think this proposal has come to the point where we need to vote.

And the vote will be for or against Peter's original proposal. Ie. change the date formats to ISO and not having this configurable.

If you do want to enhance the current date format and want it configurable you should vote AGAINST this proposal and put forward a new.

-- KennethLavrsen - 23 Apr 2007

FreetownReleaseMeeting2007x04x23

No vote since proposer and main concern raiser were not there. But the general mood was to reject this original idea and counter proposal a site level configurable format. Will be taken up at next meeting again.

Peter, I propose that you consider a new proposal with a simple configurable solution instead of a hard coded ISO format because the mood both in this topic and at FreetownReleaseMeeting2007x04x23 was that you will not get the needed majority for it. But this does not mean that people want to stick to the existing English format instead. The basic problem is recognized.

-- KennethLavrsen - 23 Apr 2007

I find this is unfortunate because it does not allow us to go one step at a time. ISO date format makes it much easier to manipulate dates (sort, compare etc), is unambigous, is readable, and is not language dependent. I guess habits are stronger than doing the right thing to internationalize the TWiki product.

While I agree that a configurable date handling is the ultimate goal, I will not have the resources to create a new, more extensive proposal and implementation for a configurable date handling feature.

-- PeterThoeny - 24 Apr 2007

Well. Looking at the code it seems to be a quite easy task.

Let us start with a list of where a configurable date format would be needed.

• %REVINFO% TWikiVariable. Currently shown as r37 - 2007-05-26 - 03:19:38 - PeterThoeny. The $date part default would change as a result of this new setting. This would change the date format in the upper right corner in PatternSkin
• %DATE% - Currently shown as 24 Apr 2007 would affect the default signature format and the time format in the copy/paste field in edit mode.
• %DISPLAYTIME% - Shown as 2026-01-15 - 10:11 - Seems to not affect any UI. At least it is not used in standard distro templates. This format should change anyway to be consistant.
• %SERVERTIME% - shown as 24 Apr 2007 - 01:05 - same as above when no format given.
• %GMTIME% - shown as 24 Apr 2007 - 08:05 - without a format given should default like above

So looking at the code - all time string generation is in ONE function TWiki::Time::formatTime and this function takes a format parameter which simply could become a configurable string. Then it is a simple matter of replaceing the hard coded "$day $mon $year" where applicable.

Let us look at the magnitude.

In TWIki.pm

sub DATE {
    my $this = shift;
    return TWiki::Time::formatTime(time(), '$day $mon $year', 'gmtime');
}

In Render.pm

sub renderRevisionInfo {
    my( $this, $web, $topic, $meta, $rrev, $format ) = @_;
    ASSERT($this->isa( 'TWiki::Render')) if DEBUG;
    my $store = $this->{session}->{store};
    my $users = $this->{session}->{users};

    if( $rrev ) {
        $rrev = $store->cleanUpRevID( $rrev );
    }

    unless( $meta ) {
        my $text;
        ( $meta, $text ) = $store->readTopic( undef, $web, $topic, $rrev );
    }
    my( $date, $user, $rev, $comment ) = $meta->getRevisionInfo( $rrev );

    my $wun = '';
    my $wn = '';
    my $un = '';
    if( $user ) {
        $wun = $users->webDotWikiName($user);
        $wn = $users->getWikiName( $user );
        $un = $users->getLoginName($user);
    }

    my $value = $format || 'r$rev - $date - $time - $wikiusername';
    $value =~ s/\$web/$web/gi;
    $value =~ s/\$topic/$topic/gi;
    $value =~ s/\$rev/$rev/gi;
    $value =~ s/\$time/TWiki::Time::formatTime($date, '$hour:$min:$sec')/gei;
    $value =~ s/\$date/TWiki::Time::formatTime($date, '$day $mon $year')/gei;
    $value =~ s/(\$(rcs|http|email|iso))/TWiki::Time::formatTime($date, $1 )/gei;
    if( $value =~ /\$(sec|min|hou|day|wday|dow|week|mo|ye|epoch|tz)/ ) {
        $value = TWiki::Time::formatTime( $date, $value );
    }
    $value =~ s/\$comment/$comment/gi;
    $value =~ s/\$username/$un/gi;
    $value =~ s/\$wikiname/$wn/gi;
    $value =~ s/\$wikiusername/$wun/gi;

    return $value;
}

In TWikiUserMapping.pm

sub addUser {
    my ( $this, $login, $wikiname ) = @_;

    ASSERT($login) if DEBUG;

    # SMELL: really ought to be smarter about this e.g. make a wikiword
    $wikiname ||= $login;

    my $store = $this->{session}->{store};
    my( $meta, $text ) = $store->readTopic(
        undef, $TWiki::cfg{UsersWebName}, $TWiki::cfg{UsersTopicName} );

    my $result = '';
    my $entry = "   * $wikiname - ";
    $entry .= $login . " - " if $login;
    my $today = TWiki::Time::formatTime(time(), '$day $mon $year', 'gmtime');

    # add to the mapping caches
    my $user = _cacheUser( $this, $wikiname, $login );

    # add name alphabetically to list
    foreach my $line ( split( /\r?\n/, $text) ) {
        # TODO: I18N fix here once basic auth problem with 8-bit user names is
        # solved
        if ( $entry ) {
            my ( $web, $name, $odate ) = ( '', '', '' );
            if ( $line =~ /^\s+\*\s($TWiki::regex{webNameRegex}\.)?($TWiki::regex{wikiWordRegex})\s*(?:-\s*\w+\s*)?-\s*(.*)/ ) {
                $web = $1 || $TWiki::cfg{UsersWebName};
                $name = $2;
                $odate = $3;
            } elsif ( $line =~ /^\s+\*\s([A-Z]) - / ) {
                #   * A - <a name="A">- - - -</a>^M
                $name = $1;
            }
            if( $name && ( $wikiname le $name ) ) {
                # found alphabetical position
                if( $wikiname eq $name ) {
                    # adjusting existing user - keep original registration date
                    $entry .= $odate;
                } else {
                    $entry .= $today."\n".$line;
                }
                # don't adjust if unchanged
                return $user if( $entry eq $line );
                $line = $entry;
                $entry = '';
            }
        }

        $result .= $line."\n";
    }
    if( $entry ) {
        # brand new file - add to end
        $result .= "$entry$today\n";
    }
    $store->saveTopic( $TWiki::cfg{SuperAdminGroup},
                       $TWiki::cfg{UsersWebName},
                       $TWiki::cfg{UsersTopicName},
                       $result, $meta );
    return $user;
}

And finally in Time.pm

sub formatTime  {
    my ($epochSeconds, $formatString, $outputTimeZone) = @_;
    my $value = $epochSeconds;

    # use default TWiki format "31 Dec 1999 - 23:59" unless specified
    $formatString ||= '$day $month $year - $hour:$min';
    $outputTimeZone ||= $TWiki::cfg{DisplayTimeValues};

    my( $sec, $min, $hour, $day, $mon, $year, $wday);
    if( $outputTimeZone eq 'servertime' ) {
        ( $sec, $min, $hour, $day, $mon, $year, $wday ) =
          localtime( $epochSeconds );
    } else {
        ( $sec, $min, $hour, $day, $mon, $year, $wday ) =
          gmtime( $epochSeconds );
    }

    #standard twiki date time formats
    if( $formatString =~ /rcs/i ) {
        # RCS format, example: "2001/12/31 23:59:59"
        $formatString = '$year/$mo/$day $hour:$min:$sec';
    } elsif ( $formatString =~ /http|email/i ) {
        # HTTP header format, e.g. "Thu, 23 Jul 1998 07:21:56 EST"
        # - based on RFC 2616/1123 and HTTP::Date; also used
        # by TWiki::Net for Date header in emails.
        $formatString = '$wday, $day $month $year $hour:$min:$sec $tz';
    } elsif ( $formatString =~ /iso/i ) {
        # ISO Format, see spec at http://www.w3.org/TR/NOTE-datetime
        # e.g. "2002-12-31T19:30:12Z"
        $formatString = '$year-$mo-$dayT$hour:$min:$sec';
        if( $outputTimeZone eq 'gmtime' ) {
            $formatString = $formatString.'Z';
        } else {
            #TODO:            $formatString = $formatString.  # TZD  = time zone designator (Z or +hh:mm or -hh:mm) 
        }
    }

    $value = $formatString;
    $value =~ s/\$seco?n?d?s?/sprintf('%.2u',$sec)/gei;
    $value =~ s/\$minu?t?e?s?/sprintf('%.2u',$min)/gei;
    $value =~ s/\$hour?s?/sprintf('%.2u',$hour)/gei;
    $value =~ s/\$day/sprintf('%.2u',$day)/gei;
    $value =~ s/\$wday/$WEEKDAY[$wday]/gi;
    $value =~ s/\$dow/$wday/gi;
    $value =~ s/\$week/_weekNumber($day,$mon,$year,$wday)/egi;
    $value =~ s/\$mont?h?/$ISOMONTH[$mon]/gi;
    $value =~ s/\$mo/sprintf('%.2u',$mon+1)/gei;
    $value =~ s/\$year?/sprintf('%.4u',$year+1900)/gei;
    $value =~ s/\$ye/sprintf('%.2u',$year%100)/gei;
    $value =~ s/\$epoch/$epochSeconds/gi;

    # SMELL: how do we get the different timezone strings (and when
    # we add usertime, then what?)
    my $tz_str = ( $outputTimeZone eq 'servertime' ) ? 'Local' : 'GMT';
    $value =~ s/\$tz/$tz_str/geoi;

    return $value;
}

BUT BUT WARNING.

We have some intelligence built in TWiki date handling. In Time.pm we have the function parseTime. Today it handles a small selection of date formats including current default format. IF we add a configurable date there is little chance to be successful making a parse time function that can guess anything. But if the intention is to support YYYY-MM-DD then this format as a minimum needs to be added to the parseTime function.

As I see it - implementing a configurable date format - as a site wide configure setting would be very easy. As a configure setting we can be more loose on the error handling of the format. The syntax for the setting would follow the format spec of TWiki::Time::formatTime

We would need TWO extra configuration setting which is a string of the Month names and a string of the Weekday names. Current hardcoded in Time.pm as @ISOMONTH and @WEEKDAY.

I think this is all within reach.

I also want to note that the current format called iso is a bit too much "iso" for a user interface. 2026-01-15T10:11:43Z. The T and the Z sucks. Format should be 2026-01-15 10:11:43 IMHO

-- KennethLavrsen - 24 Apr 2007

ISO dates should stay under the hood, not displayed to the user. The only place where this is a problem is with the signatures. Or with form fields that use a date picker, and the date string is inserted. It would be nice if that date string would be AND iso AND parsable.

Having these things searchable smells like meta data, or even the semantic web. MediaWiki uses this notation for metadata: [[Category:Conference]].

Using this notation our dates could be written as [[date:2007-04-24]]. This could be read by TWiki as iso date and rendered back in the localized date string. This would make written out dates as in signature strings searchable.

-- ArthurClemens - 24 Apr 2007

I would not want to add this complexity to simple signatures.

The internal data format would be nice to have unique (the way the date is kept under the hood never visible to users).

BUT WATCH OUT. The many TWiki apps that search for dates using SEARCH in meta will be broken if we change the date format representation in the meta data. The places where we have time coded in META the format is simple seconds since epoch and that is the obvious format to keep. It is fast in all respects when you need to convert to the displayed format. For user defined data fields it is more difficult to change to a standard format because of the formatted search in meta based applications.

-- KennethLavrsen - 24 Apr 2007

Time::ParseDate does a very good job of parsing different date formats.

TWiki already has a notation standard: %VARIABLE{...}%. let's stay away from creating new syntaxes.

If you need a way to store dates internally, they should be stored as an integer number of seconds since midnight on 1st Jan 1970 (an epoch time). There is no good reason to use any other internal format, as this is the baseline from which all other formats can be derived.

-- CrawfordCurrie - 24 Apr 2007

The Mediawiki syntax is relatively clean.

To insert a time stamp in TWiki notation we could use:
%DATE{2007-04-24}% (note: we currently only have %DATE%).

This is better readable than %DATE{844779475}% (date in seconds).

-- ArthurClemens - 24 Apr 2007

That's not under the hood, Arthur. I really don't like the idea of having to assign a type to a string on the fly in topic text. Topics are free-form text.

Peter has already said earlier in this topic "let's focus on the proposal" and I'm reiterating that now. Peter is suggesting that TWiki-generated dates be generated in an ISO8601 compliant format. That makes perfect sense to me. I don't think we need any more sophistication than that. Note that ISO8601 specifies the timezone, which has been missed for a long time in TWiki.

Remember that JSCalendarContrib also needs to be modified to generate ISO format dates.

-- CrawfordCurrie - 24 Apr 2007

I am focussing on the motivation: "Use ISO 8601 date format for non-ambiguous date display." The proposed formats are not providing this, as iso increases ambiguity.

-- ArthurClemens - 24 Apr 2007

Crawford we cannot just go back to the original proposal. That is the same as killing it and change nothing. Because the mood in the community is clearly that the original proposal will not collect the needed majority of yes votes. So forget it or change it is the way forward.

The original Peter Thoeny proposal to hardcode ISO (without the T And Z!!! which is NerdoMeter level 5 or 6) has not been very well received. It seems that only Crawford and I have supported the original proposal and after reading the reactions I also realize that 2007-05-14 is not a date format that suits normal people. It is a geek format. I no longer support the original proposal.

And then I propose to add a configuration option (3 if we want to allow alternative spelling og month and date) but let us start with 1 option and keep it simple.

Per default this DEFAULTDATEFORMAT will be "$day $month $year" and then people can change it to "$day $mo $year" or "$year-$mo-$day" or whatever they feel like.

I have shown that this requires code changes minimum 2 - optionally 4 places replacing the hard coded "$day $month $year" by a config variable.

AND 3-4 simple lines of code in parseTime().

And a small addition in TWiki.spec

That is a reasonable scope. If we wanted to change to static value it is the exact same steps. Then you just replace the fixed string by another fixed string. You still need to also extend parseTime(). Only thing you save is the TWiki.spec job.

But I do not want to take it further and start having geek codes in the topics. I think users can live with having dates in topics as static text. If I write a topic in English I expect static english dates with it. If I write the topic in Danish I write a Danish date. There is no point in letting this proposal explode in complexity and geekiness to give dynamic format of date strings in signatures in topics.

-- KennethLavrsen - 24 Apr 2007

FreetownReleaseMeeting2007x05x07: Kenneth takes the action to re-write the proposal for a renewed decision round. Current proposal has no chance to be accepted.

-- KennethLavrsen - 07 May 2007

I have updated the original proposal so that

• Simple proposal
• Maintains current default to ease upgrade
• Enables Peter's original proposal by changing simple configure option
• Easy to test because only few formats supported

I put myself as committed implementer but I will not commit that I can have it ready for Freetown. Maybe if we extend the code freeze by a week because of Bugs current condition. I am pretty sure where to fix the code but there are also unit tests to be altered and extended.

-- KennethLavrsen - 21 May 2007

Renewed proposal accepted at release meeting.

-- KennethLavrsen - 21 May 2007

Merged to core: Bugs:Item4139, SVN 13878

-- KennethLavrsen - 25 May 2007

Excellent, thanks Kenneth!

-- PeterThoeny - 26 May 2007