Ok, why does this std.date.parse below,

|import std.stdio;
|import std.date;
|void main()
|{
|  d_time t;
|  t = parse("09-Feb-04 01:00:18");
|  writefln(std.date.toString(CalculateGMT(t)));
|}

think calculates 04 to be 1904 instead of 2004?  Shouldn't parse be a little smarter and figures that today, the year is 2005 and should figure that a two year digits of 04 should be parsed as 2004 instead of 1904?

Any ideas?

jic

On Tue, 5 Apr 2005 02:20:31 +0000 (UTC), jicman wrote:

> Ok, why does this std.date.parse below,
> 
>|import std.stdio;
>|import std.date;
>|void main()
>|{
>|  d_time t;
>|  t = parse("09-Feb-04 01:00:18");
>|  writefln(std.date.toString(CalculateGMT(t)));
>|}
> 
> think calculates 04 to be 1904 instead of 2004?  Shouldn't parse be a little smarter and figures that today, the year is 2005 and should figure that a two year digits of 04 should be parsed as 2004 instead of 1904?
> 
> Any ideas?
> 
Isn't it nice to see our old friend, the Millennium Bug, has not quite left us yet.

One technique that we used was to prefix the current century to the 2-digit year, and if the result was more than 70 years in the future, subtract 100 from the 4-digit year. This had the effect that 'today' was in a window that stretched 30yrs into the past and 70yrs into the future. So given its 2005 today, a 2-digit date of '65 would be interpreted as 2065, but '75 would interpreted as 1975.

The relative position of 'today' in the window might need to be adjusted depending on the business needs and practices you have. All you have to do is change 70 to some other more appropriate value, and the rest of the algorithm still works.

-- 
Derek
Melbourne, Australia
5/04/2005 2:35:46 PM

In article <d2sslf$o2p$1@digitaldaemon.com>, jicman says...
>
>
>Ok, why does this std.date.parse below,
>
>|import std.stdio;
>|import std.date;
>|void main()
>|{
>|  d_time t;
>|  t = parse("09-Feb-04 01:00:18");
>|  writefln(std.date.toString(CalculateGMT(t)));
>|}
>
>think calculates 04 to be 1904 instead of 2004?  Shouldn't parse be a little smarter and figures that today, the year is 2005 and should figure that a two year digits of 04 should be parsed as 2004 instead of 1904?
>
>Any ideas?
>

I'd reccomend using a four-digit year rather than "04", as it's really a "best practice" to avoid parsing/creating ambiguous dates.

Honestly, we all know that it should be 2004, but we also learned much about *not* using two digit dates over five years ago.  IMO, two digit dates are reserved for data created before the peril of such a practice became imminent. I feel that Walter got it right, and that a two-digit date is more likely to be before the year 2000 rather than after (even if it means "1904").

$0.02

- EricAnderton at yahoo

In article <d2udf1$2alc$1@digitaldaemon.com>, pragma says...

>I'd reccomend using a four-digit year rather than "04", as it's really a "best practice" to avoid parsing/creating ambiguous dates.

When I started programming, back in 1982, I started using 4 digits years! ;-) But, this parsing is done one data acquired from server logs. :-(  There is not much I can do about it.  The good thing is that all these dates are older than 2000, so I know what to do.  But I wanted just to use d libraries to do the work for me, but since I didn't get any fast replies, I wrote some code that takes care of it, so I don't even use the std.date library now.


>
>Honestly, we all know that it should be 2004, but we also learned much about *not* using two digit dates over five years ago.  IMO, two digit dates are reserved for data created before the peril of such a practice became imminent. I feel that Walter got it right, and that a two-digit date is more likely to be before the year 2000 rather than after (even if it means "1904").

yes, I understand and I agree.

>
>$0.02

By the way, your $0.02 in Dominican Pesos are worth $DR 0.84.  That's a lot. ;-) But in Euros, well, let's not go there. ;-)

thanks,

josé