You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2008/03/12 21:36:31 UTC
[NET] 1.5 Leap year processing
I think I've found a solution to the leap year processing.
At present the code tries the short date and then adds the current
year if the parse fails.
This does not work on Java 1.4 or earlier because Feb 29 1970 does not
cause a parse failure - the date is converted to Mar 1 1970.
One solution seems to be to add the current year to the short date
initially, so Feb 29 will either parse OK or cause a failure if it's
not a leap year; the date won't be changed to Mar 1.
However, I've just realised that it won't work if the current date is
in Jan or Feb the following year, i.e. 10+ months later.
Are there any OSes which display short dates more than 10 months after
the file date?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [NET] 1.5 Leap year processing
Posted by "Oberhuber, Martin" <Ma...@windriver.com>.
Hi Sebb,
Thanks for your patch, I was not aware that it had not yet been applied.
Thanks also for the new Feb29 testcases.
> The current code does not fix NET-188 for Java 1.3 and 1.4, which NET
> 1.5 is supposed to support.
>
> The problem is that the 1.3 and 1.4 Java RTLs don't generate a syntax
> error for Feb 29 1970; instead they convert it to Mar 1 1970; the code
> then replaces 1970 with the current (or previous) year. So the
> timestamp appears to parse OK, but is incorrectly parsed.
>
> The patch I posted recently does work for 1.3+, but does not support
> short dates more than about 10 months old.
Ok, I applied the patch and it's good for the Feb.29 scenario.
But I found a different problem with dates on Jan.1 when
The client computer still has Dec.31 -- which can happen
Due to time zone differences. The problem existed in the
Old code as well so it's not new with your patch.
Anyways, I commented on Jira so let's follow up discussions there.
https://issues.apache.org/jira/browse/NET-188
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Samstag, 15. März 2008 02:34
> To: Jakarta Commons Developers List
> Subject: Re: [NET] 1.5 Leap year processing
>
> On 14/03/2008, Oberhuber, Martin
> <Ma...@windriver.com> wrote:
> > Hi Sebb,
> >
> >
> > > Regex is not available in Java 1.3.
> > > Also, how does one know where the year is in the string?
> >
> >
> > Code for this already is in Commons Net, using ORO for the Regex.
> > See UnixFTPEntryParser.java line 105
>
> OK, did not realise that it used ORO.
>
> >
> > > 2.2 If previous year also gives a parse error then give up?
> >
> >
> > Hm... Well, well. The point is that we don't have a chance to
> > get it right 100%. There's just too much that can go wrong,
> > for instance:
> >
> > * Dates are in server local time, but we don't know what
> > "current time" the server thinks it has. Its clock could
> > be off by years in the worst case, making all tries to
> > correctly parse short date impossible.
> >
> > * We don't know the server time zone for sure
> >
> > * Time in the client is currently used for substituting
> > current year, but that one could also be wrong.
>
> Yes.
>
> > So - I think I'd like to give it a chance with the current year
> > and the previous year, and if both fail than create an entry
> > With a "null" date (1.1.1970 or something like that).
>
> I think the date should really be null if it cannot be determined.
>
> > Also noticed that my algorithm fails in the case where due to
> > time zone differences, the client computer still has local
> > year nnnn but server already has nnnn+1.
> >
> > Unfortunately I don't have time right now to code a patch,
>
> I've already added a patch that works for most cases.
>
> > I guess that talking about code would be better than talking
> > about concepts at this point. That being said, I don't find
> > Rory's current patch that bad that it justifies further
> > Holding off the release.
> >
> > The patch code only strikes when the previous version's code
> > Would run into a parse exception, and it seems to correctly
> > Handle the Feb.29 case... So I'm not sure what else is missing
> > That must go into a 1.5 release...
> >
>
>
> >
> > Cheers,
> > --
> > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [NET] 1.5 Leap year processing
Posted by sebb <se...@gmail.com>.
On 14/03/2008, Oberhuber, Martin <Ma...@windriver.com> wrote:
> Hi Sebb,
>
>
> > Regex is not available in Java 1.3.
> > Also, how does one know where the year is in the string?
>
>
> Code for this already is in Commons Net, using ORO for the Regex.
> See UnixFTPEntryParser.java line 105
OK, did not realise that it used ORO.
>
> > 2.2 If previous year also gives a parse error then give up?
>
>
> Hm... Well, well. The point is that we don't have a chance to
> get it right 100%. There's just too much that can go wrong,
> for instance:
>
> * Dates are in server local time, but we don't know what
> "current time" the server thinks it has. Its clock could
> be off by years in the worst case, making all tries to
> correctly parse short date impossible.
>
> * We don't know the server time zone for sure
>
> * Time in the client is currently used for substituting
> current year, but that one could also be wrong.
Yes.
> So - I think I'd like to give it a chance with the current year
> and the previous year, and if both fail than create an entry
> With a "null" date (1.1.1970 or something like that).
I think the date should really be null if it cannot be determined.
> Also noticed that my algorithm fails in the case where due to
> time zone differences, the client computer still has local
> year nnnn but server already has nnnn+1.
>
> Unfortunately I don't have time right now to code a patch,
I've already added a patch that works for most cases.
> I guess that talking about code would be better than talking
> about concepts at this point. That being said, I don't find
> Rory's current patch that bad that it justifies further
> Holding off the release.
>
> The patch code only strikes when the previous version's code
> Would run into a parse exception, and it seems to correctly
> Handle the Feb.29 case... So I'm not sure what else is missing
> That must go into a 1.5 release...
>
The current code does not fix NET-188 for Java 1.3 and 1.4, which NET
1.5 is supposed to support.
The problem is that the 1.3 and 1.4 Java RTLs don't generate a syntax
error for Feb 29 1970; instead they convert it to Mar 1 1970; the code
then replaces 1970 with the current (or previous) year. So the
timestamp appears to parse OK, but is incorrectly parsed.
The patch I posted recently does work for 1.3+, but does not support
short dates more than about 10 months old.
>
> Cheers,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [NET] 1.5 Leap year processing
Posted by "Oberhuber, Martin" <Ma...@windriver.com>.
Hi Sebb,
> Regex is not available in Java 1.3.
> Also, how does one know where the year is in the string?
Code for this already is in Commons Net, using ORO for the Regex.
See UnixFTPEntryParser.java line 105
> 2.2 If previous year also gives a parse error then give up?
Hm... Well, well. The point is that we don't have a chance to
get it right 100%. There's just too much that can go wrong,
for instance:
* Dates are in server local time, but we don't know what
"current time" the server thinks it has. Its clock could
be off by years in the worst case, making all tries to
correctly parse short date impossible.
* We don't know the server time zone for sure
* Time in the client is currently used for substituting
current year, but that one could also be wrong.
So - I think I'd like to give it a chance with the current year
and the previous year, and if both fail than create an entry
With a "null" date (1.1.1970 or something like that).
Also noticed that my algorithm fails in the case where due to
time zone differences, the client computer still has local
year nnnn but server already has nnnn+1.
Unfortunately I don't have time right now to code a patch,
I guess that talking about code would be better than talking
about concepts at this point. That being said, I don't find
Rory's current patch that bad that it justifies further
Holding off the release.
The patch code only strikes when the previous version's code
Would run into a parse exception, and it seems to correctly
Handle the Feb.29 case... So I'm not sure what else is missing
That must go into a 1.5 release...
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [NET] 1.5 Leap year processing
Posted by sebb <se...@gmail.com>.
On 13/03/2008, Oberhuber, Martin <Ma...@windriver.com> wrote:
> What about this:
>
> 1.) Use REGEX to parse year into a separate String -> will be empty or nnnn
Regex is not available in Java 1.3.
Also, how does one know where the year is in the string?
[Adding the year is easy, because the format and the string can both
have the year added at the end.]
> 2.) If year is empty, substitute current year (as seen on client) and parse the date
> 2.1 If a parse error occurs, OR result date is > 3 days in the future, try again with previous year
> (in order to account for Jan.1 on the host where client still has Dec.31)
> (allow 3 days in future to be safe in really odd timezone conditions)
>
2.2 If previous year also gives a parse error then give up?
> My Linux box (RHEL4) currently shows
> "Sep 27 17:28" for Sep 27, 2007
> "Sep 3 2007" for Sep 3, 2007
> "Mar 15 2008" for Mar 15, 2008
>
> So apparently it uses short dates only for 6 months back.
> And doesn't use short dates for future dates even if it's
> Just 2 days in the future.
Useful to know.
> I think that the FTP solution should work properly for the most
> Prevalent system and live with the fact that we don't know if
The code is designed to handle lots of different OSes.
I don't think it's fair to only support the commonest one.
> There are any obscure OS's there which keep using short dates
> Even 10 months or more after the date. It's just undefined.
>
> Correct solution will come by using new FTP MDTM / MLST commands.
Indeed.
> Cheers,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
>
>
>
>
> > -----Original Message-----
> > From: sebb [mailto:sebbaz@gmail.com]
> > Sent: Mittwoch, 12. März 2008 21:37
> > To: Commons Developers List
> > Subject: [NET] 1.5 Leap year processing
> >
> > I think I've found a solution to the leap year processing.
> >
> > At present the code tries the short date and then adds the current
> > year if the parse fails.
> > This does not work on Java 1.4 or earlier because Feb 29 1970 does not
> > cause a parse failure - the date is converted to Mar 1 1970.
> >
> > One solution seems to be to add the current year to the short date
> > initially, so Feb 29 will either parse OK or cause a failure if it's
> > not a leap year; the date won't be changed to Mar 1.
> >
> > However, I've just realised that it won't work if the current date is
> > in Jan or Feb the following year, i.e. 10+ months later.
> >
> > Are there any OSes which display short dates more than 10 months after
> > the file date?
> >
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [NET] 1.5 Leap year processing
Posted by "Oberhuber, Martin" <Ma...@windriver.com>.
What about this:
1.) Use REGEX to parse year into a separate String -> will be empty or nnnn
2.) If year is empty, substitute current year (as seen on client) and parse the date
2.1 If a parse error occurs, OR result date is > 3 days in the future, try again with previous year
(in order to account for Jan.1 on the host where client still has Dec.31)
(allow 3 days in future to be safe in really odd timezone conditions)
My Linux box (RHEL4) currently shows
"Sep 27 17:28" for Sep 27, 2007
"Sep 3 2007" for Sep 3, 2007
"Mar 15 2008" for Mar 15, 2008
So apparently it uses short dates only for 6 months back.
And doesn't use short dates for future dates even if it's
Just 2 days in the future.
I think that the FTP solution should work properly for the most
Prevalent system and live with the fact that we don't know if
There are any obscure OS's there which keep using short dates
Even 10 months or more after the date. It's just undefined.
Correct solution will come by using new FTP MDTM / MLST commands.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Mittwoch, 12. März 2008 21:37
> To: Commons Developers List
> Subject: [NET] 1.5 Leap year processing
>
> I think I've found a solution to the leap year processing.
>
> At present the code tries the short date and then adds the current
> year if the parse fails.
> This does not work on Java 1.4 or earlier because Feb 29 1970 does not
> cause a parse failure - the date is converted to Mar 1 1970.
>
> One solution seems to be to add the current year to the short date
> initially, so Feb 29 will either parse OK or cause a failure if it's
> not a leap year; the date won't be changed to Mar 1.
>
> However, I've just realised that it won't work if the current date is
> in Jan or Feb the following year, i.e. 10+ months later.
>
> Are there any OSes which display short dates more than 10 months after
> the file date?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org