[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239606#comment-13239606
]
Adrian Crum commented on LANG-796:
--
If you want to perform millisecond arithmetic, then I recommend you use long
values and avoid using the DateUtils class.
The JavaDocs seem clear to me - the method adds a day, not 8640
milliseconds.
> DateUtils.addDays does not work properly with daylight saving time (DST)
>
>
> Key: LANG-796
> URL: https://issues.apache.org/jira/browse/LANG-796
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 2.6
>Reporter: Nicola Barbiero
>
> DateUtils.addDays does not work properly with daylight saving time.
> The signature of the method is
> Date addDays(Date date, int amount)
> and the javadocs says "Adds a number of days to a date returning a new
> object. The original date object is unchanged",
> so if X=date.getTime() is the number of milliseconds of the date in input,
> the expected behaviour is that the returned Date has a number of milliseconds
> equal to X+amount*(8640), where 8640 is the number of milliseconds in
> one day.
> But when the calculation goes across the DST change date, the number of
> milliseconds added does not correspond to whole days.
> For example, here in Brussels, this code fragment:
>Date input = DateUtils.parseDateStrictly("25-03-2012_00:00", new String[]
> { "dd-MM-_HH:mm" });
>Date output = DateUtils.addDays(input, 1);
> will give:
> 'input' equals to "Sun Mar 25 00:00:00 CET 2012"==> input.getTime()
> equals to 133263000
> 'output' equals to "Mon Mar 26 00:00:00 CEST 2012" ==> output.getTime()
> equals to 133271280
> where 133271280-133263000=8280 < 8640
> (in fact 8280 is equivalent to 23h).
> Since addDays is working with objects Date, it should not be influenced by
> events like the DST.
> Proposed solution: replace the current implementation
> public static Date add(Date date, int calendarField, int amount) {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> Calendar c = Calendar.getInstance();
> c.setTime(date);
> c.add(calendarField, amount);
> return c.getTime();
> }
> based on Calendar with an implementation that works only with Date objects,
> for example:
> public static Date add(Date date, int calendarField, int amount) {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> return new Date(input.getTime() + amount * 8640l);
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239466#comment-13239466
]
Adrian Crum commented on LANG-796:
--
The current behavior is correct. The result added one day. One day is NOT equal
to 8640 milliseconds - as you can see from the result.
> DateUtils.addDays does not work properly with daylight saving time (DST)
>
>
> Key: LANG-796
> URL: https://issues.apache.org/jira/browse/LANG-796
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 2.6
>Reporter: Nicola Barbiero
>
> DateUtils.addDays does not work properly with daylight saving time.
> The signature of the method is
> Date addDays(Date date, int amount)
> and the javadocs says "Adds a number of days to a date returning a new
> object. The original date object is unchanged",
> so if X=date.getTime() is the number of milliseconds of the date in input,
> the expected behaviour is that the returned Date has a number of milliseconds
> equal to X+amount*(8640), where 8640 is the number of milliseconds in
> one day.
> But when the calculation goes across the DST change date, the number of
> milliseconds added does not correspond to whole days.
> For example, here in Brussels, this code fragment:
>Date input = DateUtils.parseDateStrictly("25-03-2012_00:00", new String[]
> { "dd-MM-_HH:mm" });
>Date output = DateUtils.addDays(input, 1);
> will give:
> 'input' equals to "Sun Mar 25 00:00:00 CET 2012"==> input.getTime()
> equals to 133263000
> 'output' equals to "Mon Mar 26 00:00:00 CEST 2012" ==> output.getTime()
> equals to 133271280
> where 133271280-133263000=8280 < 8640
> (in fact 8280 is equivalent to 23h).
> Since addDays is working with objects Date, it should not be influenced by
> events like the DST.
> Proposed solution: replace the current implementation
> public static Date add(Date date, int calendarField, int amount) {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> Calendar c = Calendar.getInstance();
> c.setTime(date);
> c.add(calendarField, amount);
> return c.getTime();
> }
> based on Calendar with an implementation that works only with Date objects,
> for example:
> public static Date add(Date date, int calendarField, int amount) {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> return new Date(input.getTime() + amount * 8640l);
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-400) Selector based on regular expressions
[
https://issues.apache.org/jira/browse/VFS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201184#comment-13201184
]
Adrian Crum commented on VFS-400:
-
Please convert your code to a patch file and attach the patch file to this
issue. When attaching your file, be sure to grant the ASF permission to use
your code.
> Selector based on regular expressions
> -
>
> Key: VFS-400
> URL: https://issues.apache.org/jira/browse/VFS-400
> Project: Commons VFS
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Rikard Oxenstrand
>Priority: Minor
>
> In the long todo list there was a post about adding a file selector based on
> regular expressions. I had need for that for a specific project so I built a
> simple class that seems to work. I'm kind of new to open source contribution
> though so I'm not sure if i should just commit it to trunk. Here is the code:
> {code:title=FileRegexSelector.java|borderStyle=solid}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.commons.vfs2;
> import java.util.regex.Matcher;
> import java.util.regex.Pattern;
> /**
> * A {@link FileSelector} that selects based on regular expressions matched
> against base filename.
> *
> * @since 2.1
> */
> public class FileRegexSelector implements FileSelector
> {
> /**
> * The extensions to select.
> */
> private Pattern pattern = null;
> /**
> * Creates a new selector for the given extensions.
> *
> * @param extensions
> *The extensions to be included by this selector.
> */
> public FileRegexSelector(String regex)
> {
> this.pattern = Pattern.compile(regex);
> }
> /**
> * Determines if a file or folder should be selected.
> * @param fileInfo
> *The file selection information.
> * @return true if the file should be selected, false otherwise.
> */
> public boolean includeFile(final FileSelectInfo fileInfo)
> {
> if (this.pattern == null)
> {
> return false;
> }
> Matcher matcher =
> this.pattern.matcher(fileInfo.getFile().getName().getBaseName());
> return matcher.matches();
> }
> /**
> * Determines whether a folder should be traversed.
> *
> * @param fileInfo
> *The file selection information.
> * @return true if descendents should be traversed, fase otherwise.
> */
> public boolean traverseDescendents(final FileSelectInfo fileInfo)
> {
> return true;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-473) Number to Boolean conversion
[
https://issues.apache.org/jira/browse/CONFIGURATION-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179663#comment-13179663
]
Adrian Crum commented on CONFIGURATION-473:
---
I understand Emmanuel's confusion. A boolean value has two states, not three.
So true/false/null does not make sense.
> Number to Boolean conversion
>
>
> Key: CONFIGURATION-473
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-473
> Project: Commons Configuration
> Issue Type: Improvement
> Components: Type conversion
>Affects Versions: 1.7
>Reporter: Emmanuel Bourg
> Fix For: 1.8
>
>
> The conversion of number values to boolean is not supported. {{0}} should be
> converted to {{false}}, and any other number should be converted to {{true}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-34) OgnlRuntime.getCompiler and thread-safety.
[
https://issues.apache.org/jira/browse/OGNL-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139183#comment-13139183
]
Adrian Crum commented on OGNL-34:
-
Problems will occur when some threads try to use a partially-constructed
instance of ExpressionCompiler.
> OgnlRuntime.getCompiler and thread-safety.
> --
>
> Key: OGNL-34
> URL: https://issues.apache.org/jira/browse/OGNL-34
> Project: OGNL
> Issue Type: Bug
>Reporter: Maurizio Cucchiara
>Priority: Minor
> Labels: concurrency, thread-safety
>
> As you can see, {{getCompiler}} is not thread safe.
> I recently added a new performance benchmark to test its 3d-safety and
> performance: during my tests I have experienced a fast execution on unsafe
> version vs the safe one (though every concurrent test instantiated a new
> compiler).
> I have not yet investigated and I still don't know what can cause running
> more than one instance of the compiler in the same jvm. If necessary we can
> consider to make compiler a singleton in order to enforce this concept.
>
> What do you think guys?
> {code}
> public static OgnlExpressionCompiler getCompiler( OgnlContext ognlContext )
>
> {
>
> if ( _compiler == null )
>
> {
>
> try
>
> {
>
> OgnlRuntime.classForName( ognlContext, "javassist.ClassPool" );
>
> _compiler = new ExpressionCompiler();
>
> }
>
> catch ( ClassNotFoundException e )
>
> {
>
> throw new IllegalArgumentException(
>
> "Javassist library is missing in classpath! Please add missed
> dependency!", e );
> }
>
> }
>
> return _compiler;
>
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-34) OgnlRuntime.getCompiler and thread-safety.
[
https://issues.apache.org/jira/browse/OGNL-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139169#comment-13139169
]
Adrian Crum commented on OGNL-34:
-
In the code you posted, more than one thread can enter the if block. That is
how you get more than one instance of the compiler.
> OgnlRuntime.getCompiler and thread-safety.
> --
>
> Key: OGNL-34
> URL: https://issues.apache.org/jira/browse/OGNL-34
> Project: OGNL
> Issue Type: Bug
>Reporter: Maurizio Cucchiara
>Priority: Minor
> Labels: concurrency, thread-safety
>
> As you can see, {{getCompiler}} is not thread safe.
> I recently added a new performance benchmark to test its 3d-safety and
> performance: during my tests I have experienced a fast execution on unsafe
> version vs the safe one (though every concurrent test instantiated a new
> compiler).
> I have not yet investigated and I still don't know what can cause running
> more than one instance of the compiler in the same jvm. If necessary we can
> consider to make compiler a singleton in order to enforce this concept.
>
> What do you think guys?
> {code}
> public static OgnlExpressionCompiler getCompiler( OgnlContext ognlContext )
>
> {
>
> if ( _compiler == null )
>
> {
>
> try
>
> {
>
> OgnlRuntime.classForName( ognlContext, "javassist.ClassPool" );
>
> _compiler = new ExpressionCompiler();
>
> }
>
> catch ( ClassNotFoundException e )
>
> {
>
> throw new IllegalArgumentException(
>
> "Javassist library is missing in classpath! Please add missed
> dependency!", e );
> }
>
> }
>
> return _compiler;
>
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-31) [PATCH] Some CPD fixes around ASTMethod and ASTStaticMethod.
[ https://issues.apache.org/jira/browse/OGNL-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13136757#comment-13136757 ] Adrian Crum commented on OGNL-31: - You might want to change the author tags in ASTMethodUtil.java. > [PATCH] Some CPD fixes around ASTMethod and ASTStaticMethod. > > > Key: OGNL-31 > URL: https://issues.apache.org/jira/browse/OGNL-31 > Project: OGNL > Issue Type: Improvement >Reporter: Adrian Cumiskey >Priority: Minor > Attachments: patch-OGNL31.txt > > > I discovered a number of PMD CPD issues around ASTMethod and ASTStaticMethod > class, there was quite a bit of duplication there. > This patch comes courtesy of the wifi connection in my local laundry-mat here > in Milwaukee. Its strange the things people will do to make their clothes > wash more quickly :-). > Cheers, Adrian. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
