Hello jmerrill, jmc> There is an absolute standard for this -- the timezone that's in jmc> an internet-style (date and) time string says that earlier times jmc> are a negative offset from GMT. (For example, the U.S. has a negative offset from GMT.)
jmc> I think you did it backwards. It must match the internet time jmc> standard -- when there are only two choices, our "some standard" jmc> should be the one that has already been chosen by the world. Thanks for the input, there is a big point in what you're saying. However, another though came to my mind: one of the primary purposes for the method suggested is to be able to get GMT time from local one easily. Then my current idea makes sense as gmtime = localtime + gmtoffset - simple & easy. However, still open to changing, and I believe Nicolas should have a final word here.. ;) Mike jmc> J. Merrill jmc> Senior Software Engineer jmc> 3M Health Information Systems, Inc. jmc> Michael Pliskin <[EMAIL PROTECTED]> jmc> Sent by: [EMAIL PROTECTED] jmc> 07/14/2008 12:02 PM jmc> Please respond to jmc> Michael Pliskin <[EMAIL PROTECTED]>; Please respond to jmc> Neko intermediate language mailing list <[email protected]> jmc> To jmc> Neko intermediate language mailing list <[email protected]> jmc> cc jmc> Subject jmc> Re: [Neko] API for local/GMT time conversion jmc> Hello Nicolas, MP>> Hmm then we're reducing the solution to just get_tz_offset function - MP>> minutes seem non-standard for me, maybe seconds is better. Ok, will MP>> make it and send a patch soon. jmc> ok, here is a simple patch. Note that I am subtracting local from GMT, jmc> so GMT+2 will have negative offset. Not sure if it is the best but we jmc> just need to stick to some convention. -- Best regards, Michael mailto:[EMAIL PROTECTED] -- Neko : One VM to run them all (http://nekovm.org)
