Message107155
| Author |
belopolsky |
| Recipients |
belopolsky, brian.curtin, docs@python, georg.brandl, napik, techtonik |
| Date |
2010年06月05日.17:43:57 |
| SpamBayes Score |
0.07602243 |
| Marked as misclassified |
No |
| Message-id |
<AANLkTinwNcQDui2LLr5rEPpiuIUCmnVP5T1nrxsMdDIC@mail.gmail.com> |
| In-reply-to |
<1275758643.04.0.779704816395.issue7229@psf.upfronthosting.co.za> |
| Content |
On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik
<report@bugs.python.org> wrote:
..
> As for offtopic UTC vs GMT - I doubt there is a way to clearly express that the offset sign of the
> returned values is negated in comparison with real "UTC offsets" without resorting to some
> king of alternative east/west scale.
Sure there is. Here is how RFC 3339 handles this:
"""
Numeric offsets are calculated as "local time minus UTC". So the
equivalent time in UTC can be determined by subtracting the offset
from the local time.
"""
and here is a quote from MacOS man page for tzset:
"""
offset Indicates the value one must add to the local
time to arrive at Coor-
dinated Universal Time.
"""
No geographic reference needed. (And the issue is not UTC vs. GMT:
both UTC and GMT are timescales, sometimes even considered the same.
The off-topic issue is UTC vs. Prime Meridian.) |
|