#287 closed enhancement (fixed)
timezone fixes
Reported by: | Jim Ursetto | Owned by: | felix winkelmann |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | core libraries | Version: | 4.5.x |
Keywords: | Cc: | ||
Estimated difficulty: |
Description ¶
In C_decode_seconds, on platforms that do not consult tm_gmtoff (currently everything other than OS X), the local timezone offset is always reported in the 10-element time vector. It should report the offset from UTC (0). The attached patch does that.
This change preserves the "UTC-ness" of the time object so that, if a user accepts 10-element time values in his own eggs, he can know the actual timezone offset without external help. I'd like to use this fixed behavior in a egg I am working on.
I think syn is having a somewhat related issue with DST, which we will tackle in another ticket.
Change History (10)
Changed 14 years ago by
Attachment: | 0001-C_decode_seconds-should-report-zero-timezone-offset-.patch added |
---|
comment:1 Changed 14 years ago by
Owner: | set to felix winkelmann |
---|---|
Status: | new → accepted |
comment:2 Changed 14 years ago by
Changed 14 years ago by
Attachment: | 0002-Use-tm_gmtoff-for-all-GNU-environment-platforms-Linu.patch added |
---|
Changed 14 years ago by
Attachment: | 0003-Correct-polarity-on-gmtoff-to-tmvec-conversions-fixe.patch added |
---|
comment:3 Changed 14 years ago by
Summary: | seconds->utc-time doesn't zero out its timezone → timezone fixes |
---|
Patch 0002 changes seconds->local-time to use tm_gmtoff for all platforms that support it, not just OS X. As this is a BSD extension (present since BSD4.3-Reno) it is widely available. Currently we just use the local timezone, which is incorrect when calculating a time with DST not equal to current time (or if, say, timezone rules changed in the past). For example, on my machine, the second timezone offset should be 21600, because DST is in effect:
(seconds->local-time 0) ;=> #(0 0 19 31 11 69 3 364 #f 18000) (seconds->local-time) ;=> #(48 45 21 19 6 110 1 199 #t 18000)
(Note that the timezone offset is always inclusive of DST and the dst flag is just advisory.
This does not fix the issue on Windows or some other platforms, but that would require more hacks, so I am punting on that.
comment:4 Changed 14 years ago by
Patch 0003 fixes an oversight in the polarity of tm_gmtoff when a struct tm is being copied in and out of a vector. tm_gmtoff is seconds east of UTC, while our 10-element vector holds seconds west of UTC. This is already handled in C_decode_seconds but not in the generic vector copy code.
(time->string (seconds->local-time) "%z") ;=> "+0500" ; before patch (time->string (seconds->local-time) "%z") ;=> "-0500" ; after
strftime handling of %Z and %z is actually pretty iffy regardless; typically %Z will ignore the timezone offset you provide and just use your local timezone, and %z doesn't even correct for DST on OS X. There's nothing we can do about this. However, I fixed the bug anyway because it is a genuine issue in tm_gmtoff handling.
comment:6 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Patches applied in "experimental" branch.
Hold off from applying for a couple hours, I have two other small patches to add which totally fix Moritz's problem. Or I can open another ticket.