> If it's all UTC then there's no daylight savings issue. Plus given > the rate at which we simulate, we'd have to have a very poorly chosen > starting time & date to simulate across a leap second (from > http://en.wikipedia.org/wiki/Leap_second: > "Leap seconds occur only at the end of a UTC month, and have only ever > been inserted at the end of June 30 or December 31."). > > So if our canonical fake wall-clock time is Jan 1 (which I think it > is), we'd have to simulate 6 months to hit a leap second... > > Basically I don't see a problem with using the library functions.
Ok, I'm just worried that there are hidden things lurking in those library functions. They're not simple. You may notice that python doesn't even implement any timezone stuff in its library and leaves it up to the user. That's because it's not simple and it changes. I agree that UTC should be relatively safe though. An idle CPU could allow us to actually simulate 6months time :) I also worry that tzset isn't the same across unix/macos/windows. The main reason I'm so worried is that this could be a (perhaps unlikely) source of simulator differences that would potentially be very difficult to hunt down. Anyway, I think I'm not going to waste any more time talking about it since the code would take less time to write than to extend this discussion. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
