FYI

-------- Forwarded Message --------
Subject: Re: svn commit: r1770547 - in /velocity/tools/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools: ConversionUtils.java generic/DateTool.java
Date:   Wed, 23 Nov 2016 20:59:43 +0100
From:   Michael Osipov <micha...@apache.org>
To:     cla...@renegat.net



Hi Claude,

not being subscribed to the Velocity dev list, though being a happy
Velocity user and Maven Doxia developer relying on Velocity, here are my
thoughts on this:

Having access to ISO 8601 (neither ISO-8601, nor ISO8601) in the
original German version through my employer (unfortunately, I cannot
share due to legal reasons), I can shed some light here.

I have raised the same issues with Commons Lang, all of them have been
addressed some time ago.

1. The 'T' is always mandatory, *unless* it has been mutually agreed to
replace it for a space (U+0020). It is a safe bet to name iso-human but
not having it as default.
2. Consider that you have used the extended format (s. Common Lang).
Don't forget that there is also a basic format. Document that at least.
3. There is no need to reference to RFC when you have always an ISO
standard applied by half of the planet.
4. "yyyy-MM-dd'T'HH:mm:ssX and "yyyy-MM-dd HH:mm:ssX" are incomplete if
you have offsets by 30 or 45 minutes. You are simply truncating them.
Unless you know and you probably don't, always stick with XXX in
extended format.
5. ISO operates on timezone *offsets* (except Zulu) not on timezones
like Olson TZ DB.
6. I consider 435 to 441 being inconsisting to their counterpart 420 to 423.

I would really try to make a difference between ISO and ISO for humans
because people mostly do not care about timezones, they want to have it
in their local one.

iso, iso-human, iso-tz (does not apply to date only), iso-human-tz (does
not apply to date only) (ideally with an Olson TZ ID?)

Feel free to contact me in case of questions/ideas.

Best regards,

Michael

Reply via email to