On Tue, Jun 19, 2012 at 03:32:47PM -0700, Eliot Miranda wrote:
On Tue, Jun 19, 2012 at 1:50 PM, Igor Stasenko <siguctua@gmail.com> wrote:
IMO epoch starting is completely orthogonal to timezone bug which should simply fixed. If you define epoch time as 1 jan 1970 (or any other date you prefer) but still will mess up with timezones, it won't change anything isn't?
Absolutely right.
+1. In Cog the VM has a 64-bit microsecond clock which is available both as microseconds from 1901 UTC and in local time. This is a great basis as it eliminates millisecond clock rollover issues (every 49 days?), lasts for
50,000 years, and needs only the one primitive to answerUTC in up to microsecond resolution, fully synchronised. VW has been using such a basis for about a decade. If we could add these time primtiievs to the Interpreter IMO we'd have a much better basis for time.
Eliot, Could I ask you to please take a second look at primitiveUtcWithOffset? This has been in trunk VMMaker with platform support for Windows/Unix/Mac for a couple of years now, and the background and discussion is on Mantis at http://bugs.squeak.org/view.php?id=7458. The underlying platform call is ioUtcWithOffset(&clock, &offset) which could presumably be adapted to support your Cog primitives. Would this make sense? Dave