Re: Time zone trouble without time zones being involved

[Yuri Khan <yuri.v.khan@gmail.com>]

On Wed, Apr 13, 2016 at 10:14 PM, Michael Heerdegen
<michael_heerdegen@web.de> wrote:

>> 1. Mark the current UTC time, both as a human-readable string and as a
>> unixtime value (e.g. on GNU, “date --utc --rfc-3339=seconds” and “date
>> +%s”, respectively).
>> 2. Make a commit.
>> 3. Execute the same command, “git log --pretty=format:%ad
>> --date=format:%s -n1”.
>> 4. Evaluate (current-time) and convert the first two elements of the
>> resulting 4-element list to unixtime.
>> 5. Check that the three unixtime values from steps 1, 3 and 4 are
>> reasonably close.
>
> I'm not sure how to do 4.  However, 1. and 3. already give me a
> difference of ~ 60*60.
>
> What does this tell us?

From what it looks like, either git or libc are misinformed about your
time zone.

I was hoping you’d post the actual values you see at each step. I
would then independently convert the unixtime into a date and time to
see they are sane. Your wall clock reading would be useful too.

(current-time) is documented thus in my copy of Emacs 24:

    Return the current time, as the number of seconds since 1970-01-01 00:00:00.
    The time is returned as a list of integers (HIGH LOW USEC PSEC).
    HIGH has the most significant bits of the seconds, while LOW has the
    least significant 16 bits.  USEC and PSEC are the microsecond and
    picosecond counts.

so you take the first element, multiply it by 65536, add the second element.

Example: I just now got this tuple: (22286 29507 190287 275000). 22286
* 65536 + 29507 = 1460564803. “date +%s” says 1460564877 so my Emacs
and the rest of my system agree and it took me just over a minute to
do the calculation.

>> 6. By the way, which OS are you on?
>
> uname -a => "Linux drachen 4.4.0-1-amd64 #1 SMP Debian 4.4.6-1
> (2016-03-17) x86_64 GNU/Linux".  Mostly Debian testing.

Good. What is your $TZ (if any), what does your /etc/timezone contain,
and is your tzdata package fresh enough?