Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Commits missing timezone information #92

Closed
rtomayko opened this Issue · 10 comments

5 participants

Ryan Tomayko Michael Ding Vicent Marti Carlos Martín Nieto nulltoken
Ryan Tomayko

When a commit is read via Rugged::Repository#lookup, the Time objects exposed from the author and committer are always in UTC. The timezone provides important information about the commit and should be available. The Time#mktime method should allow creating new Time objects with a specified tz.

Michael Ding

+1

Vicent Marti
Owner

Time#mktime method should allow creating new Time objects with a specified tz.

Not under 1.8.7; this only applies to 1.9+. What should I do with the old Ruby? I don't see any way of defining a timezone, besides local and UTC.

Carlos Martín Nieto
Owner

FWIW pygit2 exposes it as part of the author information so you access it with commit.author.offset.

Vicent Marti
Owner

I see. That may be a valid approach in 1.8.7, whilst in 1.9.2 we could set the offset properly in the Time object... Although I don't like the idea of having different APIs based on the version.

This ought to be a solved problem... I can't believe that 1.8.7 doesn't have proper support for timezones.

Ryan Tomayko

Yeah I'm totally baffled by not being able to create Time objects with a custom timezone in 1.8.7. I thought Grit gave back proper time objects but its ignoring the timezone entirely and uses the unix time.

I guess I like the idea of always using UTC in 1.8.7 and exposing the zone offset separately.

An alternate approach would be to expose to an ISO8601 string version of the timestamp in addition to the time object.

Vicent Marti
Owner
vmg commented

Gotcha. Do you want proper timezones in 1.9, though? Or would you rather keep the API consistent?

Ryan Tomayko

So at this point I really don't even care about the Time object. I just want an ISO8601 string representation that retains the original time zone info. This can be a totally separate accessor. Right now we're just converting the Time object into an ISO8601 string anyway so all this round-trip through Time is doing is losing data.

nulltoken

tl;dr; The offset can not always be resolved to a timezone.

The offset is the number of minutes from UTC, including the daylight saving time policy at this date.

This means:

  • Some different timezones may share the same offset at some point in the year
  • The same timezone may have a different offset along the year
Ryan Tomayko

That's fine. I need the information that's in the commit. I can establish time of day and approximate timezone at least.

This is really so fundamental. It should always be possible to recreate the exact same object from the data libgit2/rugged exposes. I should be able to take the information exposed by these interfaces and recreate the raw objects and have them checksum down to the same sha1. This is a really simple and important stick to measure against. If you can't recreate the object data, then I'd say it should be classified as a bug.

As of right now it's impossible to generate a same commit object from the information exposed by Rugged.

Ryan Tomayko

Fixed in #158

Ryan Tomayko rtomayko closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.