[ 
https://issues.apache.org/jira/browse/JSPWIKI-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571766#action_12571766
 ] 

Goran Karlic commented on JSPWIKI-196:
--------------------------------------

Dirk, I find both your ideas good. This seems to me the best solution for the 
things discussed here. It would make things quite configurable.

* What is the pattern for the value parameter in the DATE plugin?
* Should this pattern support explicit time zones?
* What is the pattern's implicit time zone - UTC or server? 

My argumentation here:
* ISO-8601 (2008-02-28 17:12:18) should be used for the pattern, optional 
precision to the second
* Explicit time zones would leave it more flexible (f. i. 2008-02-28 
18:12:18+0100)
* Implicit UTC would make content moveable between servers in different 
timezones  (f. i. 2008-02-28 17:12:18+0100)

Janne: being myself an astronomer I might be too sensitive about time zones and 
I might be overdoing it on ISO-8601; I am neither a fan nor non-fan of ISO-8601 
- it is just that I don't know about a better default.


> Consistent date and time formats
> --------------------------------
>
>                 Key: JSPWIKI-196
>                 URL: https://issues.apache.org/jira/browse/JSPWIKI-196
>             Project: JSPWiki
>          Issue Type: Improvement
>          Components: Localization
>    Affects Versions: 2.6.1
>         Environment: Any
>            Reporter: Goran Karlic
>            Priority: Trivial
>
> +This issue was changed to better reflect the initiated discussion+
> Focus is on:
> * How DateTimes are *stored* internally, for example as page content or 
> metadata (comments etc.)
> * How they are *rendered* to end-users in their browsers
> {quote}
> The original issue name was:  _Date and time formats according to ISO 8601_. 
> We have multiple occurences of hard-coded or context-unaware DateTime to 
> String conversions (page properties, JSPs, templates).
> My proposal is to rely on an international standard instead of using an 
> invented default. The current international standard is ISO 8601 (s. 
> Wikipedia). My further proposal is to show time with the precision to the 
> second, as the SI unit system defines the second as the basic unit of time. 
> Furthermore "GMT" is replaced by "UTC" and they might differ up to a second 
> (s. Wikipedia).
> I think this will make unlocalized strings more transparent to the users and 
> easier to decode correctly (consider 02/03/08 - is it in the future or in the 
> past - or might it even be the current time?!).
> Following this proposal java format strings allowed for above cases would be: 
> (1) Simple date: "yyyy-MM-dd" ("The daily mail for 2008-02-20 was sent")
> (2) Date and time
> (2.1) Explicit time context: "yyyy-MM-dd hh:mm:ssZ" ("User gkarlic made this 
> at 2008-02-20 22:38:10+0100")
> (2.2) Implicit time context: "yyyy-MM-dd hh:mm:ss" ("This server lives on 
> CET, here it is 2008-02-20 22:38:10")
> Where (2.1) would be used for strings that might emerge from different 
> time-zones.
> If others agree with this proposal, I would gladly make the required changes.
> {quote}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to