Skip to content


Commits missing timezone information #92

rtomayko opened this Issue · 10 comments

5 participants


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.




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.


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


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.


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.

vmg commented

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


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.


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

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.


Fixed in #158

@rtomayko 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.