Can't build phobos

[Freddy via Digitalmars-d-learn]

On Monday, 4 August 2014 at 10:30:40 UTC, Marc Schütz wrote:
> On Sunday, 3 August 2014 at 23:41:27 UTC, Freddy wrote:
>> I am currently working on a phobos fork to include associative
>> ranges, however the unittest fail when i try to build. How am a
>> supposed test any unittests that i add.
>> link:https://github.com/Superstar64/phobos/tree/associative_ranges
>>
>> $ ../dmd/src/dmd |head -1
>> DMD32 D Compiler v2.066-devel-9d6cef9
>>
>>
>> 0.030s PASS std.algorithm
>> 0.023s PASS std.array
>> 0.034s PASS std.ascii
>> 0.001s PASS std.base64
>> 0.006s PASS std.bigint
>> 0.003s PASS std.bitmanip
>> 0.000s PASS std.complex
>> 0.002s PASS std.concurrency
>> 0.023s PASS std.conv
>> 0.000s PASS std.cstream
>> 0.001s PASS std.csv
>> ****** FAIL std.datetime
>> core.exception.AssertError at std/datetime.d(1398): [2012-Apr-30
>> 01:00:00] [2012-Apr-30 00:00:00]
>> ----------------
>> generated/linux/debug/32/unittest/libphobos2-ut.so(void
>> std.datetime.SysTime.__unittestL1363_26()+0xd08) [0x41b35ea0]
>> generated/linux/debug/32/unittest/libphobos2-ut.so(void
>> std.datetime.__modtest()+0xdd) [0x41d6e6ed]
>> generated/linux/debug/32/unittest/test_runner(bool
>> test_runner.tester()+0x104) [0x8049524]
>> generated/linux/debug/32/unittest/libphobos2-ut.so(runModuleUnitTests+0xd1)
>> [0x42cce4c1]
>> generated/linux/debug/32/unittest/libphobos2-ut.so(void
>> rt.dmain2._d_run_main(int, char**, extern (C) int
>> function(char[][])*).runAll()+0x2d) [0x42cedd45]
>> generated/linux/debug/32/unittest/libphobos2-ut.so(void
>> rt.dmain2._d_run_main(int, char**, extern (C) int
>> function(char[][])*).tryExec(scope void delegate())+0x2a)
>> [0x42cedcea]
>> generated/linux/debug/32/unittest/libphobos2-ut.so(_d_run_main+0x152)
>> [0x42cedc5a]
>> generated/linux/debug/32/unittest/test_runner(main+0x14)
>> [0x804968c]
>> /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3) 
>> [0x430a2a83]
>
>
> That's curious. I cannot reproduce this... Unfortunately I 
> don't have time to look into it right now. Is it possible that 
> the test uses the system's timezone definitions, which might 
> somehow be buggy on your computer?
That is probably it, I am going to commentout that line not stage
it.