Salut Claude,
Am 2016-11-29 um 17:22 schrieb Claude Brisson:
The DateTool should now be fixed:
- the stupid bug about date formats ignoring time zone has been fixed
- the new standard formats are iso / iso_tz for ISO 8601, and intl /
intl_tz for the human-readable versions which use time zone
The DateTool should now be fixed:
- the stupid bug about date formats ignoring time zone has been fixed
- the new standard formats are iso / iso_tz for ISO 8601, and intl /
intl_tz for the human-readable versions which use time zone IDs for
formatting.
See commit
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
On 24/11/2016 20:41, Michael Osipov wrote:
Am 2016-11-24 um 17:40 schrieb Sergiu Dumitriu:
On 11/24/2016 02:29 AM, Claude Brisson wrote:
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
Am 2016-11-24 um 17:40 schrieb Sergiu Dumitriu:
On 11/24/2016 02:29 AM, Claude Brisson wrote:
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
Am 2016-11-24 um 08:29 schrieb Claude Brisson:
Glad to receive an enlightened opinion on the subject.
4. "-MM-dd'T'HH:mm:ssX and "-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
On 11/24/2016 02:29 AM, Claude Brisson wrote:
>> 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
Glad to receive an enlightened opinion on the subject.
On 23/11/2016 20:59, Michael Osipov wrote:
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
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.
Thanks again for your review.
On 21/11/2016 07:22, Sergiu Dumitriu wrote:
Although RFC 3339 says that "Applications [...] may choose, for the sake
of readability, to specify a full-date and full-time separated by (say)
a space character", the standard is to use T as a separator.
And if I'm
Although RFC 3339 says that "Applications [...] may choose, for the sake
of readability, to specify a full-date and full-time separated by (say)
a space character", the standard is to use T as a separator.
And if I'm already nagging, ISO and RFC are two different things, as are
ISO-8601 and RFC
11 matches
Mail list logo
