[Issue 2917] std.date fails for all years before 1970

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon May 4 03:39:02 PDT 2009


http://d.puremagic.com/issues/show_bug.cgi?id=2917





------- Comment #1 from ghaecker at idworld.net  2009-05-04 05:39 -------
Created an attachment (id=348)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=348&action=view)
patch for std.date.d v. 2.029 fixes issues with negative time values

Rather than whine about the date issues, I decided to lend a hand and address
the issues myself.  If you find the modifications useful you are welcome to use
the code in any way you see fit.  I only added my name as a modifier so that
Walter won't get blamed for any mistakes I made.  You may remove my name or
leave it, as you see fit.  The changes I made aren't anything special; just
some grunt work that needed doing.

I tinkered with some of the more vital functions in this module.  In
particular, I modified floor(), dmod(), day(), and dayFromYear().  The latter
got a little messy with year value 0 and lower.  Of course, pushing the
Gregorian calendar back that far back is purely hypothetical.  I added unittest
sections to day() and dayFromYear, as the proper working of these functions is
vital to the entire module.

I threw in a bit of trivial tidying up as well.  The calls to toInteger() and
timeClip() were removed, since they don't do anything.  I left the functions in
place, in case some existing code calls them.  I changed the name of the 'day'
variable that called the day() function, as it seems like a bad idea to
duplicate the name in the same scope.

I added an overload for dateFromTime(d_time t, int months).  In most cases,
where it's used in the module, the value for month is already known, so there's
no need for dateFromTime() to recalculate it.

My addition of toDbDateTime() is trivial, but I found it useful in testing, and
it has practical value.  It's a fairly common format, and it doesn't add much
weight to the module.

I also added two other functions: addMonths() and addYears().  These are both
common date/time-manipulation tasks, which aren't as straightforward as adding
fixed values like days or weeks.  addMonths() is rather clunky, but it gets the
job done.  It never cranks through more than 11 months on any call.  Beyond 11,
it calls addYears() so that adding 60 months is almost as quick as adding 5
years.

I've rebuilt the 2.029 library with this patch to std.date on linux.  All
appears to be working well.  Someone needs to test the DosDate functions to
make sure my changes didn't break them.  There were no unit tests for them.  I
don't have D installed on a Windows box.

Thanks in advance for considering these changes.


-- 



More information about the Digitalmars-d-bugs mailing list