| === echo-are` is now known as echo-area | ||
| === SamB_ is now known as SamB | ||
| mark06 | hi, are commit date and times stored as UTC in the case the detected timezone is incorrect? | 20:16 |
|---|---|---|
| mark06 | for example, when using bzr from MinGW MSYS under a non-English Windows | 20:17 |
| mark06 | more info: http://stackoverflow.com/questions/12765650/mingw-msys-msvcrt-and-the-tz-environment-variable/13126574 | 20:23 |
| mark06 | what's the exact behavior of log's --timezone=utc? will it just shift the time by the stored timezone? | 20:27 |
| mark06 | or is the time stored as utf with a timezone shift indicator? for example, if summer time ends today at midnight and clock is reverted one hour back, we got two 23:00-0:00 periods in the current timezone, one for summer time, and another for standard time | 20:29 |
| mark06 | say my standard time is -03:00, so if I commit something in one of the two 23:00-0:00 periods, I'll get either a -02:00 or -03:00 indicator in the log, right? | 20:32 |
| mark06 | now consider that for some reason bzr could have detected the timezone incorrectly at the time of commit (like described in the post) | 20:33 |
| mark06 | so can I rely on --timezone=utc for telling me the real UTC not just shifting stored time by the stored timezone? | 20:34 |
| mark06 | please help! :( | 20:40 |
| vila | mark06: bzr uses whatever timezone is set to derive utc. It doesn't matter how it's stored, there is no way for bzr to 'detect that the timezone is incorrect'. Garbage in, garbage out. Now, bzr doesn't care about commit times because there is no way to decide that your clock is correct, TZ or not. A revision comes after another revision because there is parent/child relationship, no matter what the revision dates are. Why do you care about | 21:05 |
| vila | those commit times ? | 21:05 |
| mark06 | I have a script that detects incorrect timezones in bazaar commits, I don't want bazaar to work properly, it's rather a bug fix for MSYS as explained in that post | 21:13 |
| mark06 | If they're not important, why not remove commit times at all? That's why I care about them | 21:15 |
| mark06 | what I want is what I asked, what's the exact behavior of log's --timezone=utc? just shift the stored time by the stored timezone, OR show the UTC time which is actually how the time is stored (that is, the shift operation happens on display time only, not on store time) | 21:18 |
| mark06 | take as example commit date "2013-02-16 23:00 -02:00", will --timezone=utc just show "2013-02-16 01:00 UTC" (just a shift with the stored value), or will it show *either* "2013-02-16 01:00 UTC" or "2013-02-16 02:00 UTC" (those being the two possibilities for when (1) timezone was correct on commit and it's the "first" 23:00 -- before adjusting clock backward one hour, or (2) timezone is incorrect with daylight period just having started, the time b | 21:25 |
| mark06 | ah sorry, *"2013-02-17 01:00 UTC" | 21:26 |
| mark06 | *"2013-02-17 01:00 UTC", *"2013-02-17 01:00 UTC" | 21:27 |
| mark06 | *"2013-02-17 02:00 UTC" | 21:27 |
| mark06 | the mentioned script is here, as you can see in the comments there, I appreciate if anyone can clarify (with arguments) about --timezone=utc: http://bazaar.launchpad.net/~renatosilva/+junk/scripts/view/head:/check-brst-commits.sh | 22:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!