> Consider please, > Windows is able to work with equivalent of struct tm in kernel and > contains conversion functions and Linux too.
Neither one surprises me - and neither one is good IMO. > Not easy to explain details of the overall data flow, important for > porting to NetBSD is to minimize differences, I can argue this either way. On the one hand, yes, minimizing differences when porting is, generally speaking, a good thing. But, on the other hand, introducing botches into a system to accomodate software design that itself is so badly botched it assumes their presence is probably a bad thing; the right thing (I do not say, the easy thing) is to fix the misdesign. If porting something to NetBSD requires importing zoneinfo into the kernel, I think that thing desperately needs fixing. I can understand wanting to just take the expedient path (I've been trying for years to work myself out of a project that has been doing that for longer than I've been involved in it, and, as much as I hate it, I think it _usually_ has been a right choice, given their tradeoffs). But I do not think the resulting horror belongs in NetBSD proper. That same project has other hackery in the kernel, none of which I have tried to push upstream because I think it doesn't belong in NetBSD. If I want a kitchen-sink kernel I know where to find Linux. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
