[Issue 2917] std.date fails for all years before 1970
https://issues.dlang.org/show_bug.cgi?id=2917 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Version|2.029 |D2 --
[Issue 2917] std.date fails for all years before 1970
http://d.puremagic.com/issues/show_bug.cgi?id=2917 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@kyllingen.net Resolution||WONTFIX --- Comment #7 from Lars T. Kyllingstad bugzi...@kyllingen.net 2011-02-03 00:13:24 PST --- std.date has now been superseded by std.datetime. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2917] std.date fails for all years before 1970
http://d.puremagic.com/issues/show_bug.cgi?id=2917 downs default_357-l...@yahoo.de changed: What|Removed |Added CC||default_357-l...@yahoo.de --- Comment #6 from downs default_357-l...@yahoo.de 2010-05-22 11:07:48 PDT --- This bug report is symptomatic for what's wrong with the D development process, in my opinion. There's a bug, there's a fix, there's a patch, there's a distinct lack of feedback from Walter/Andrei. No wonder so few people work on D; a situation like this would drive any contributor away. My apologies to Mr. Haecker. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2917] std.date fails for all years before 1970
http://d.puremagic.com/issues/show_bug.cgi?id=2917 --- Comment #4 from Glenn Haecker ghaec...@idworld.net 2010-01-25 02:59:44 PST --- Created an attachment (id=555) patch for std.date.d v.2.039 fixes issues with negative time values -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2917] std.date fails for all years before 1970
http://d.puremagic.com/issues/show_bug.cgi?id=2917 --- Comment #5 from Glenn Haecker ghaec...@idworld.net 2010-01-25 03:12:00 PST --- Created an attachment (id=556) date_assert.d contains assertions for date.d v2.039 patch date_assert.d contains test cases, both to demonstrate what's wrong with std.date and to validate modifications by the supplied patch. Please note that this file and the provided patch were created on Linux and contain UNIX-style line endings. In order to compile date_assert.d with v2.039 phobos before the patch is applied, you'll need to comment out lines 68 through 84. These lines contain tests that call addMonths(), which is not available before the patch is applied. You can search for fails w/o patch to identify the assert() tests that fail with out the patch. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2917] std.date fails for all years before 1970
http://d.puremagic.com/issues/show_bug.cgi?id=2917 --- Comment #2 from Glenn Haecker ghaec...@idworld.net 2009-05-14 16:20:06 PDT --- Created an attachment (id=366) -- (http://d.puremagic.com/issues/attachment.cgi?id=366) patch for std.date.d v. 2.030 fixes issues with negative time values -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2917] std.date fails for all years before 1970
http://d.puremagic.com/issues/show_bug.cgi?id=2917 --- Comment #3 from Glenn Haecker ghaec...@idworld.net 2009-05-14 17:06:15 PDT --- This bit of code shows the bug. There are larger effects as well. --- string[] testdt = [ 1969-12-31 23:59:58 UTC, 1969-12-31 23:59:59 UTC, 1970-01-01 00:00:00 UTC, // epoch 1970-01-01 00:00:01 UTC, 1970-01-01 00:00:02 UTC]; foreach(int i, string s; testdt) writefln(%s = %5d, s, parse(s)); d_time[] times = [-2000,-1000,0,1000,2000]; foreach(tm; times) writefln(%5d = %s, tm, toUTCString(tm)); --- Unpatched results: 1969-12-31 23:59:58 UTC = -9223372036854775808 (d_time_nan) 1969-12-31 23:59:59 UTC = -9223372036854775808 (d_time_nan) 1970-01-01 00:00:00 UTC = 0 1970-01-01 00:00:01 UTC = 1000 1970-01-01 00:00:02 UTC = 2000 -2000 = Wed, 31 Dec 1969 23:59:57 UTC (off by 1 sec) -1000 = Wed, 31 Dec 1969 23:59:58 UTC (off by 1 sec) 0 = Thu, 01 Jan 1970 00:00:00 UTC 1000 = Thu, 01 Jan 1970 00:00:01 UTC 2000 = Thu, 01 Jan 1970 00:00:02 UTC Patched results: 1969-12-31 23:59:58 UTC = -2000 1969-12-31 23:59:59 UTC = -1000 1970-01-01 00:00:00 UTC = 0 1970-01-01 00:00:01 UTC = 1000 1970-01-01 00:00:02 UTC = 2000 -2000 = Wed, 31 Dec 1969 23:59:58 UTC -1000 = Wed, 31 Dec 1969 23:59:59 UTC 0 = Thu, 01 Jan 1970 00:00:00 UTC 1000 = Thu, 01 Jan 1970 00:00:01 UTC 2000 = Thu, 01 Jan 1970 00:00:02 UTC -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2917] std.date fails for all years before 1970
http://d.puremagic.com/issues/show_bug.cgi?id=2917 --- Comment #1 from ghaec...@idworld.net 2009-05-04 05:39 --- Created an attachment (id=348) -- (http://d.puremagic.com/issues/attachment.cgi?id=348action=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. --
