4 ms·

There is a possible issue though - would they commit immediately after coding - how long do they need to work on a commit before actually committing it?

glandium 7y ago
Another issue is that when you travel to a different timezone, you don't necessarily update the timezone of your system.
- cptskippy 7y ago
  Aren't most devices configured to adjust automatically these days?
  - mattlondon 7y ago
    I personally don't travel with my desktop :) Generally I take a small light laptop when traveling, and then just connect to the desktop back home for doing real work such as committing code. I know that at a lot of Big Cos do not let their engineers to have source code on laptops anyway (so easily lost and stolen).
    - inlined 7y ago
      At least Google has made an exception for me when I’m working on code hosted on Github. Most of that is (or will be) public so there’s low risk.
  - glandium 7y ago
    Neither my Linux nor Windows 10 laptops do.
    - Kye 7y ago
      Both can be configured to do this, but I'm not sure it's enabled by default.
  - franciscop 7y ago
    In the blog post it specifies that it uses the Unix timestamp, which doesn't account for timezones.
    - donatj 7y ago
      It's Unix timestamp followed by timezone.
    - cptskippy 7y ago
      Yes and that's most irrelevant because we were discussing the device offset as users travel between timezones. Unix Timestamps are always expressed as UTC/TUC which remain constant regardless of device offsets. The origianl comment's assertion that users don't typically adjust their offsets is moot since commits are stored in UTC anyways. I was just pointing out that many devices automatically adjust offsets.
iosonofuturista 7y ago
For one or two isolated commits, that is a fair question. But with hundreds I think it evens out. A more detailed analysis could also take in account the number of changes. How many files per commit? How many lines, maybe? The day of week is also a very interesting metric, that is very visible e.g. on github's timeline. I know my busiest days in terms of commits are in the middle of the week, a marked decrease on Friday afternoons, and if there are commits in the weekend, they most likely contain swearing in the message. Edit: I'm betting Brad Fitzpatrick's pattern in Go (current job?) and memchached (not current job?) would vary in terms of day of week, not just hour.
- azernik 7y ago
  It wouldn't even out - you never commit before writing code, so any measurement based on commit times will be consistently biased to later times.
amelius 7y ago
And perhaps they commit first thing in the morning, after a nightly test succeeded (or perhaps they simply forget to commit at night). Another useful graph would be commit volume versus time (where volume is e.g. number of lines modified)
jfroma 7y ago
I think is different for every person. I usually commit often but I'd squash multiple commits into one. So, my graph isn't exactly going to tell you at what hours I code but at what time I sent pull requests to my coworkers for example.

glandium 7y ago

Another issue is that when you travel to a different timezone, you don't necessarily update the timezone of your system.

cptskippy 7y ago
Aren't most devices configured to adjust automatically these days?
- mattlondon 7y ago
  I personally don't travel with my desktop :) Generally I take a small light laptop when traveling, and then just connect to the desktop back home for doing real work such as committing code. I know that at a lot of Big Cos do not let their engineers to have source code on laptops anyway (so easily lost and stolen).
  - inlined 7y ago
    At least Google has made an exception for me when I’m working on code hosted on Github. Most of that is (or will be) public so there’s low risk.
- glandium 7y ago
  Neither my Linux nor Windows 10 laptops do.
  - Kye 7y ago
    Both can be configured to do this, but I'm not sure it's enabled by default.
- franciscop 7y ago
  In the blog post it specifies that it uses the Unix timestamp, which doesn't account for timezones.
  - donatj 7y ago
    It's Unix timestamp followed by timezone.
  - cptskippy 7y ago
    Yes and that's most irrelevant because we were discussing the device offset as users travel between timezones. Unix Timestamps are always expressed as UTC/TUC which remain constant regardless of device offsets. The origianl comment's assertion that users don't typically adjust their offsets is moot since commits are stored in UTC anyways. I was just pointing out that many devices automatically adjust offsets.

iosonofuturista 7y ago

For one or two isolated commits, that is a fair question. But with hundreds I think it evens out. A more detailed analysis could also take in account the number of changes. How many files per commit? How many lines, maybe? The day of week is also a very interesting metric, that is very visible e.g. on github's timeline. I know my busiest days in terms of commits are in the middle of the week, a marked decrease on Friday afternoons, and if there are commits in the weekend, they most likely contain swearing in the message. Edit: I'm betting Brad Fitzpatrick's pattern in Go (current job?) and memchached (not current job?) would vary in terms of day of week, not just hour.

azernik 7y ago
It wouldn't even out - you never commit before writing code, so any measurement based on commit times will be consistently biased to later times.

amelius 7y ago

And perhaps they commit first thing in the morning, after a nightly test succeeded (or perhaps they simply forget to commit at night). Another useful graph would be commit volume versus time (where volume is e.g. number of lines modified)

jfroma 7y ago

I think is different for every person. I usually commit often but I'd squash multiple commits into one. So, my graph isn't exactly going to tell you at what hours I code but at what time I sent pull requests to my coworkers for example.