Opened 6 years ago

Closed 6 years ago

#3515 defect closed fixed (fixed)

Timezone logged incorrectly when between -1 and -59 minutes offset from UTC

Reported by: exarkun Owned by:
Priority: normal Milestone:
Component: core Keywords:
Cc: Branch: branches/negative-tzoffset-3515
(diff, github, buildbot, log)
Author: exarkun Launchpad Bug:

Description

As reported initially on #3513, if a tzoffset is negative and less than one hour, it is incorrectly written to the log as the absolute value of the offset.

Attachments (1)

log.diff (2.7 KB) - added by wangchun 6 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 6 years ago by exarkun

  • author set to exarkun
  • Branch set to branches/negative-tzoffset-3515

(In [25189]) Branching to 'negative-tzoffset-3515'

comment:2 Changed 6 years ago by exarkun

(In [25190]) fix the tzoffset reporting

refs #3515

comment:3 Changed 6 years ago by exarkun

  • Keywords review added
  • Owner exarkun deleted

Changed 6 years ago by wangchun

comment:4 Changed 6 years ago by wangchun

Patch updated and attached.

comment:5 Changed 6 years ago by wangchun

According to RFC 2822:

The form "+0000" SHOULD be used to indicate a time zone at Universal Time. Though "-0000" also indicates Universal Time, it is used to indicate that the time was generated on a system that may be in a local time zone other than Universal Time and therefore indicates that the date-time contains no information about the local time zone.

I believe the formatTime got localtime here, and we should use %Y-%m-%dT%H:%M:%S-0000 here for London.

But in RFC 3339:

If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. RFC2822 [IMAIL-UPDATE] describes a similar convention for email.

It seems we should not use "-0000" for a known time zone.

UNIX strftime returns +0000 in London, so the patch attached.

comment:6 Changed 6 years ago by exarkun

The proposed fix is in the branch indicated in the ticket description area - branches/negative-tzoffset-3515. I didn't base it off of your original patch because it was easier to start over than to remove the unrelated changes. If you want to suggest further changes, the best way to do so is with a patch against the branch, rather than against trunk. Please don't include changes not related to this ticket (you can file more tickets for other changes :), eg the addition of 'T' to the middle of the time format.

comment:7 Changed 6 years ago by therve

  • Keywords review removed
  • Owner set to exarkun

Great, please merge.

comment:8 Changed 6 years ago by exarkun

  • Resolution set to fixed
  • Status changed from new to closed

(In [25286]) Merge negative-tzoffset-3515

Author: exarkun
Reviewer: therve
Fixes: #3515

Fix the formatting done by FileLogObserver of timezone offsets
between -1 and -59 minutes (ie, log events emitted in Liberia
before May 1, 1972 or in Ireland between 1880 and October 1, 1916).

Previously these timezone offsets would be incorrectly reported as
positive rather than negative.

comment:9 Changed 3 years ago by <automation>

  • Owner exarkun deleted
Note: See TracTickets for help on using tickets.