pytz question: GMT vs. UTC

S

Skip Montanaro

According ato the pytz doc (http://pytz.sourceforge.net/):

"‘UTC’ is Universal Time, also known as Greenwich Mean Timeor GMT in
the United Kingdom."

If they are equal, why don't timezone objects created from those two
strings compare equal?
False

(I'm revealing my complete ignorance of timezone manipulation by
asking this question.)

Thx,

Skip
 
G

Grant Edwards

According ato the pytz doc (http://pytz.sourceforge.net/):

"UTC is Universal Time, also known as Greenwich Mean Time or GMT in
the United Kingdom."

If they are equal,

The question is _are_ they equal?

There is an exact defintion for what "UTC" is, and there's another
exact definition of what UT1 is (more about this later). Civil
timezones are defined as offsets from UTC.

It seems that "GMT" no longer has an exact definition (at least from a
metrologist's perspective) can be used to mean either UTC or UT1. UTC
and UT1 can differ by up to 1 second. Leap seconds are occasionally
added to UTC to keep it from drifting more than 1 second from UT1.

From a metrology point of view, what was originally called "GMT"
(solar time at 0 degrees longtitude) is now called "UT1". So some
people rightly claim that "GMT" means UT1. But nobody actually _uses_
UT1 (except metrologists and astronomers).

All civil time is based on UTC: the official time in Greenwich (except
during BST) is not UT1, it's UTC. So some other people rightly claim
that "GMT" refers to UTC.

In a software libary context, I would say that GMT should mean UTC and
they ought to be considered equal and should always produce identical
results. In a metrology context, people saying "GMT" probably ought
to be smacked across the knuckes with a 12-inch platinum-iridium ruler
and asked to try again until they specify either UTC or UT1 (or some
other precisely defined UT-flavor).

http://en.wikipedia.org/wiki/Universal_Time
 
C

Chris Angelico

Under what temperature/pressure conditions is that ruler?

STP, of course. And the smack must be administered in exactly 1G
environment, to ensure proper impact.

ChrisA
 
D

Dennis Lee Bieber

STP, of course. And the smack must be administered in exactly 1G
environment, to ensure proper impact.
How cruel... I suspect the smack at 0degC is much more painful than one
at room temperature <G>
 
M

MRAB

How cruel... I suspect the smack at 0degC is much more painful than one
at room temperature <G>
It's the 21st century; you should be making use of Unicode: 0°C.
 
C

Chris Angelico

It's the 21st century; you should be making use of Unicode: 0°C.

I started to read that and thought you were going to advocate the use of 0°K...

ChrisA
 
W

wxjmfauth

Le jeudi 30 janvier 2014 04:27:54 UTC+1, Chris Angelico a écrit :
I started to read that and thought you were going to advocate the use of 0°K...

======

The temperature unit is the "Kelvin", not the "Degree Kelvin".
One writes: 0 K, 275.15 K

It can also be the "Degree Celsius", not the "Celsius".
One writes: -273.15 °C, 0 °C


.... print(ud.name(c))
....
DEGREE FAHRENHEIT
KELVIN SIGN
DEGREE CELSIUS
DEGREE SIGN
jmf
 
W

wxjmfauth

Le jeudi 30 janvier 2014 10:49:11 UTC+1, Christian Heimes a écrit :
It's 0 K. The SI-unit 'Kelvin' has no degree (although Lord Kelvin was a

professor). *g*


Glad, that you read (received?) my previous post!
 
M

MRAB

Le jeudi 30 janvier 2014 04:27:54 UTC+1, Chris Angelico a écrit :

======

The temperature unit is the "Kelvin", not the "Degree Kelvin".
One writes: 0 K, 275.15 K
Not that long ago I saw a science fiction film in which one of the
"scientists" said "degrees Kelvin". The rest of the "science" was
somewhat dubious too...
 
G

Grant Edwards

The temperature unit is the "Kelvin", not the "Degree Kelvin".
One writes: 0 K, 275.15 K

And remember to say "Kelvins" not "Kelvin" when speaking about
temperatures other than 1 K.
 
C

Chris Angelico

ObPython: My program retrieves temperatures (in Kelvins) from an
external device (the details of which I am not at liberty to discuss)
and stores them in the cloud (because that's where all the cool kids
store data these days), and there's something really weird going on.


$ python ./program.py
temperature1 is -100 K
temperature2 is 100 K
temperature2 is hotter than temperature1

But everyone knows that -100K is hotter than 100K. I tried converting
to UTC, but that didn't help. What am I missing?

I'm sorry, you have completely misunderstood the problem here. You are
storing data in the cloud, which means you're representing everything
with water. It is therefore fundamentally illogical to use any
temperature outside the range [273.15K, 373.15K], because otherwise
your cloud will freeze or boil, and either way, it'll crash badly.

Plus, converting to UTC? Puh-leeze. You should be using kilogram
meters per second.

ChrisA
 
R

Rustom Mody

Le jeudi 30 janvier 2014 04:27:54 UTC+1, Chris Angelico a écrit :

The temperature unit is the "Kelvin", not the "Degree Kelvin".
One writes: 0 K, 275.15 K

OMG! OMG!!
That is an ASCII K and not a unicode K

Now poor jmf will suffer the fire and brimstone of hell without
diacrïticál marks
 
W

wxjmfauth

Le vendredi 31 janvier 2014 08:02:22 UTC+1, Rustom Mody a écrit :
OMG! OMG!!

That is an ASCII K and not a unicode K



Now poor jmf will suffer the fire and brimstone of hell without

diacrïticál marks

====

I'm aware of what I did.

1) You wrote: "That is an ASCII K and not a unicode K".

This is a non sense. You are opposing ascii and unicode,
the reperoire of the ascii chars and the repertoire of the
Unicode chars.

In unicode, the are two "K"'s, one for the letter and one
for the Kelvin unit, see my previous post.

2) I used the letter "K" for commodity. Btw, I'm also
aware the 'KELVIN SIGN' is not availaible in many fonts.

3) If you wish to discuss the typographical aspect
in that story, one can discuss the kind of space which
should separate the number and the unit ('SPACE',
'SOFT HYPHEN', 'NARROW NO-BREAK SPACE',
'HAIR SPACE', ...). My "lazy" white space can also be
considered as a mistake.

4) What is definitively wrong is to claim :

"It's the 21st century; you should be making use of
Unicode: 0°C."

The 'DEGREE SIGN' and "Unicode" are two different
things. It exists in many coding schemes.


cs = ['iso-8859-1', 'iso-8859-2', 'cp437', 'cp850', 'cp1252', 'cp857',\
'iso-8859-15']
for c in cs:
c, '\u00b0'.encode(c, 'replace').decode(c)
cs = ['iso-8859-1', 'iso-8859-2', 'cp437', 'cp850', 'cp1252', 'cp857',\ .... 'iso-8859-15']
for c in cs:
.... c, '\u00b0'.encode(c, 'replace').decode(c)
....
('iso-8859-1', '°')
('iso-8859-2', '°')
('cp437', '°')
('cp850', '°')
('cp1252', '°')
('cp857', '°')
('iso-8859-15', '°')
5) Not unicode. The "°" is available as "direct (Shift) key"
on many European keyboards.

6) Finally and for the record : "n Kelvin" and not "n Degree Kelvin".

jmf
 
M

Mark Lawrence

On 31/01/2014 10:17, (e-mail address removed) wrote:

Is the double line spacing that you still use despite being asked not to
ASCII or unicode?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top