Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
From: Michael Schwarz <michi.schwarz@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_0DB3B031-F49C-46F9-A58E-756F59073300"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: Is %z broken for return values of time.gmtime()?
Date: Mon, 16 Sep 2013 22:55:33 +0200
References: <3C2755B3-2478-45E1-88F5-9FD961F2B1BD@gmail.com> <1379354161.1707.22675889.2647208B@webmail.messagingengine.com>
To: "python-list@python.org" <python-list@python.org>
In-Reply-To: <1379354161.1707.22675889.2647208B@webmail.messagingengine.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.36.1379364943.18130.python-list@python.org>
Lines: 96
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:54244


--Apple-Mail=_0DB3B031-F49C-46F9-A58E-756F59073300
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On 2013-W38-1, at 19:56, random832@fastmail.us wrote:

> On Mon, Sep 16, 2013, at 9:15, Michael Schwarz wrote:
>> According to the documentation of time.gmtime(), it returns a =
struct_time
>> in UTC, but %z is replaced by +0100, which is the UTC offset of my =
OS=92s
>> time zone without DST, but DST is currently in effect here (but was =
not
>> at the timestamp passed to gmtime()).
>=20
> The struct_time type does not include information about what timezone =
it
> is in.

Uhm =85 Python 3.3 introduced the tm_gmtoff member of struct_time, which =
contains the offset to UTC. I thought, %z was also introduced in Python =
3.3 and so I thought it would use that field. What time zone does it use =
then? Does it always use the system's time zone?

> You can use datetime.datetime (e.g. datetime.datetime.fromtimestamp(40 =
*
> 365 * 86400,datetime.timezone.utc) - the datetime.datetime class has a
> strftime method.

I do use that, but I was using time.localtime() to convert a POSIX =
timestamp to a date using the system's timezone and saw that while a =
struct_time produced by time.localtime() and formatted using =
time.strftime() shows the correct time zone (+0100 and +0200 here), it =
does not for a struct_time produced by time.gmtime(). I think that's =
strange.

> You should be aware that %F and %T are not portable and won't work on
> windows for example.

I=92m aware of that, but thanks. I was toying around and just needed to =
print the rest of the date.

Regards
Michael=

--Apple-Mail=_0DB3B031-F49C-46F9-A58E-756F59073300
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFQjCCBT4w
ggMmoAMCAQICAwrPojANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTEwMTAxMzQ1MDVaFw0x
MzEwMDkxMzQ1MDVaMEIxGDAWBgNVBAMTD01pY2hhZWwgU2Nod2FyejEmMCQGCSqGSIb3DQEJARYX
bWljaGkuc2Nod2FyekBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDA
UvCv85S3/L+IJjn/3VTz5kf1afiAvb6UZHyQQ2eZr9HVvqjl9r4QUVbLohLPmLv3prwnFvVg3oOP
mjGk6tbD4h4wxvz/y98FIBjQdK8Zb48gjoqunmLrzAWjYsBCkh29oe5gNlFkBuSOgTvQiuRYSuMA
6ftV/ss7FWfc1wM4dlTsK1GAfw7lChH0Mi9XW6izluY5ReWZ8tM9cRaHsf4SrDCDY7IJ/PxyHxYz
wwH/mrDGBgqhkSASVuAMVgboQQX8B5Yhqbr0aODD3e03WOVjwn5fSVvWngzCtlbPncWUTw0sSI2z
HxjQFd0ry8YYC+cURk4CnGqxdTJ5cZm0gXX/AgMBAAGjggEEMIIBADAMBgNVHRMBAf8EAjAAMFYG
CWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBv
dmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUH
AwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYI
KwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwIgYDVR0RBBswGYEXbWljaGkuc2Nod2Fy
ekBnbWFpbC5jb20wDQYJKoZIhvcNAQEFBQADggIBAIcJY+RtmKxmpaUHVe5aTREziEixHvuSca5W
tiQ25bg0Ui5h0UZNw5drI3wOKWObXEYru6XzG+AppBRpQKR7uwAePjz9S7m3eW2fZMpojjoAmCBv
lWbZ+EQJYJ6ez4GnrDDL14FoyRw9Fo8BBG2ohdDtesqWdzoJg48XvWioGGEDh/7DSDepPcm0QVYZ
GZfSI78VTblav/Lp0N43XP8rMcQMyqIBwdMpZhuNB2LNS44uwZOj7d3GZzvN753G2uMtOXtgQjGH
3WGy3ZMRnXsVmfxbwdsfoc8ieR1yN3+C2YEyt6LQDVt1irJm2mPwm4clicq++Iy/O8Ji1044Zy3t
WaOCPBccsL+M3cxIWw0szVUUn0moNUSQ6J4R6jpmUuxQZkiVD5Dq+PV1fAim5banu83+2pz2DO3O
9Et6ZQElCoD/jpo2CiIvzfXcXwV1Q0QKq2E0YJC2YHyETkbfUeqBOHgb3EkY7nPE1HLr4iYwSjN3
VTS8OxnQW0f3Ek3dTuEx15tgGzHm2CpV5ZRye1u1xyFy+2pftMwU2M2fepiGmOycc919w70q8FWh
5k9r0P0Ttm5EoFslC8fdOkqyOyvxQ4TKpzDCKUgO/0mjGD5sg93hrM7NDpkNeGqg0VbrMtPgaDDx
XB02dLODgTRyepUWMq5fK4AJO9fWBNwB7hpdRCYuMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMH
Um9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0
IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwrP
ojAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMzA5MTYyMDU1MzRaMCMGCSqGSIb3DQEJBDEWBBTcTPttdUl4auKPF8YeqKGoj9m0VjCBkQYJ
KwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Y2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3
DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKz6IwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAO
BgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu
b3JnAgMKz6IwDQYJKoZIhvcNAQEBBQAEggEAqmjkvo+jMGKt5HJsnUk0bCx8YJSPqGC3HtEqacpG
WYwpElrbzODGlnDAq/nvKwSoMViMmYOSLAWcf+iViapVlcjLOoKUwv8YKJ6GiE38zRQQyGR1N0pn
zuG6hSRVsIbCxBflhJW8YQ16yWynP70lPVbu6iGbIhekItU5jO/VgVQBWhplk60MG9THacZQDCZJ
c1Y5rY76nMiD7/OuwuIc64f9txLFTYFasgSRQvTJ+ZkFwQ4pwxi1gCX5b7skx2lzXANNGaaplVnQ
p6PspIzEbyHor93Hns/1PBoAKsVJ4yRra7Y2fz9XjA+41lgz54jWXYSJRI9ePXVOYFJjTKTr0wAA
AAAAAA==

--Apple-Mail=_0DB3B031-F49C-46F9-A58E-756F59073300--