Feature Proposal: Allow TIME macros to format any old time value, not just the current time

Motivation

Presently, the only way to re-format a date (epoch seconds or otherwise) is by using SpreadSheetPlugin. It seems quite strange our VarDATE, VarGMTIME, VarDISPLAYTIME and VarSERVERTIME macros go 99% the way to doing what I want, except they can only format the current time().

Description and Documentation

1) Extend Foswiki::Time (and thus System.TimeSpecifications) to auto-interpret a string consisting only of digits 4 or more in length, or beginning with an - or + sign (and having only digits following) as epoch seconds since 1970 GMT.

2) VarGMTIME, VarDISPLAYTIME, VarDATE, VarSERVERTIME implement some new optional parameters:

• epoch - the time to be formatted, in seconds since 1970 GMT (c.f. $epoch format token)
• time - the time to be formatted, as a string matching one of the supported Foswiki TimeSpecifications. If the time string lacks timezone information:
  • For VarGMTIME, the time string is assumed to be in GMT
  • For VarSERVERTIME, the time string is assumed to be local server time
  • For VarDISPLAYTIME, the time string is assumed to be in GMT or local server time, depending on {DisplayTimeValues} setting in configure.
  • For VarDATE, the time string is assumed to be in GMT or local server time, depending on {DisplayTimeValues} setting in configure.

If both time and epoch are supplied, emit an inline foswikiAlert.

Examples

%GMTIME{
  "$iso"
  epoch="1330258200"
}%
%DISPLAYTIME{
  "$day $month, $year - $hour:$min:$sec"
  time="2012-02-26T01:11:20Z"
}%

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: PaulHarvey - 26 Feb 2012

Discussion

It sucks I can't make time auto-detect an epoch seconds, but seconds very near to 1970 might be indistinguishable from 2 or 4 digit years, unless they're zero padded, and I'm not sure that's useful.

-- PaulHarvey - 26 Feb 2012

Let's get real about this; 1970 was a long time ago. For a few-digit year to be misinterpreted as an epoch, it would have to fall in the range 0...9999. This corresponds to an epoch time between 1970-01-01 00:00:00Z and 1970-01-01 02:46:39Z. So if you auto-interpret any number greater than 9999 as an epoch time, no-one is going to weep.

-- CrawfordCurrie - 26 Feb 2012

We have modern (post-1970) data pertaining to specimens which have a presence in the wiki for convenience which have collection dates as far back as 1770 (actually, I bet we have annotations on some Kew, British Museum of Natural History records which go back even further) but I agree, interpreting numbers greater than 9999 as an epoch time is probably okay.

That should probably be handled in Foswiki::Time, I have updated the proposal accordingly.

-- PaulHarvey - 26 Feb 2012

"1970 was a long time ago." can't be real. There are wiki apps covering dates and events even before 1970ies. Not being able to do such wiki apps sounds unreal.

That's when I found out that Time::Local does just fine without the 1900 tricks in Foswiki::Time. See Tasks.Item11308. So if an integer is treated as epoch seconds including negative epoch seconds, we are indeed able to format any date, not only those late enuf past 1970.

The two digits being ambiguous in parseTime() might only be required for TablePlugin to get sorting coulmns right. I don't know of any other place where somebody would take any two digits as year numbers automatically. Thus I consider this more of a bug than a feature getting in the way more often than it helps.

-- MichaelDaum - 26 Feb 2012

We are not talking about not being able to do wikiapps. We are talking about the interpretation of a numeric string such as "1970". Following my proposal, this would be interpreted as a date. In fact, any single number in the range 0000 to 9999 will be interpreted as a date. Any number outside of that range will be interpreted as an epoch time. This has nothing to do with the 1900 tricks, and indeed, anything other than pure digits will be interpreted by parsing as a time and can never be misinterpreted as an epoch. Of course you may feel that a number such as "-2012" should be interpreted as 2012BCE (or 2013BCE as some experts insist) but IMHO the range of "pure number dates" should be restricted to CE (not sure ISO8601 even considers BCE; anyone know?)

The main issue here is whether we consider supporting the ISO8601 basic format, which would be misinterpreted as an epoch date; in basic format, today is 20120227. In this case an epoch date would be indistinguishable, and would require some non-standard prefix or postfix to distingusih it e.g. e20120227

-- CrawfordCurrie - 27 Feb 2012

I'd like to see us switch to using the CPAN:DateTime library for date/time manipulation and formatting. Our own code is a bit weak in places. Anyway, flipping this to accepted proposal, no objections have been raised and the 14 days is long since passed.

-- GeorgeClark - 09 Oct 2012

There was discussion about replacing Foswiki::Time with something from CPAN back in 2009. See ReplaceFoswikiTimeModule.

-- AndrewJones - 10 Oct 2012

A merge with DateTimeContrib libs would be possible.

-- ArthurClemens - 10 Oct 2012

I had a look at DateTimeContrib and was expecting it to use the CPAN:DateTime module. Alas, it doesn't. Why? Another issue with this extension as it is at the moment is its configure based way to localize. This definitely should be following standards paths.

-- MichaelDaum - 24 Apr 2013

I'm pushing this out to 2.0. Probably makes sense to tackle this with I18N work

-- GeorgeClark - 02 Apr 2014

Changing to parked. Needs adoption by a developer. And really with the above discussions about CPAN modules, and extensions, could probably stand for a refresh.

-- GeorgeClark - 19 Nov 2015

Commenting is disabled while not logged in