Am 2016-11-24 um 08:29 schrieb Claude Brisson:
Glad to receive an enlightened opinion on the subject.
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.
It's XXX in the code. ssX appeared only in the mail discussion on the
dev list.
I know, I am just telling intentionally not have this copied to the code.
6. I consider 435 to 441 being inconsisting to their counterpart 420
to 423.
Oh, you're speaking about line numbers in ConversionUtils.java... why is
it inconsistent? When we're speaking about date only, there is no
timezone or separator involved, so it's the same format.
Yes, but it seems to be superseded by another commit already.
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?)
I like it.
By Olson TZ ID, I guess you refer to "zzz" (aka CET), and not "zzzz"
(aka Central European Time), don't you?
No, never ever use this braindead RFC three-letter timezones. They are
not standardized, not unambigious. Invented in the dark ages of the
Internet.
See here: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
They are fully supported by java.util.TimeZone.
Unfortunately, SimpleDateFormat does not support them as format option.
I highly recommend to drop those bits in r1771188.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
