Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have ls installed on my Windows XP computer. It came with msysgit. I've had it a while and it turns out I use it quite a lot even in the DOS prompt. More than dir.

The thing is that it gives me time stamps with one hour offset. See the date for gcc.exe, ls says 15:01, dir says 16:01:

C:\MinGW\bin>ls --full-time gcc.exe
-rwxr-xr-x    1 gaf      Administ    90112 Thu Apr 24 15:01:53 2008 gcc.exe

C:\MinGW\bin>dir gcc.exe
 Volymen i enhet C har ingen etikett.
 Volymens serienummer är 644A-83A3

 Innehåll i katalogen C:\MinGW\bin

2008-04-24  16:01            90 112 gcc.exe
               1 fil(er)              90 112 byte
           0 katalog(er)  104 458 203 136 byte ledigt

(sorry for the strange language)

I can tell that it is ls that is doing it wrong, I checked that with newly created files.

It's quite disturbing, any suggestion on how I can solve that?


EDIT: more info added after njd's answer.

Changing the env variable TZ does have effect. I live in Sweden, where time is CET in winter, CEST in summer. I tested both UTC, CET, and CEST, and reached strange (for me) results:

C:\Program\Git\bin>set TZ=UTC

C:\Program\Git\bin>.\date
Mon Feb 15 12:53:26 GMT 2010

C:\Program\Git\bin>set TZ=CET

C:\Program\Git\bin>.\date
Mon Feb 15 12:53:50 GMT 2010

C:\Program\Git\bin>set TZ=CEST

C:\Program\Git\bin>.\date
Mon Feb 15 12:53:59 GMT 2010

C:\Program\Git\bin>set TZ=CET+1

C:\Program\Git\bin>.\date
Mon Feb 15 11:54:27 CET 2010

C:\Program\Git\bin>set TZ=CET-1

C:\Program\Git\bin>.\date
Mon Feb 15 13:54:35 CET 2010

Setting TZ to CET or CEST has no effect. The date displayed is still GMT. It seems that the string CET alone has no effect. Is it only a string for displaying, and is only taken into account if there is a explicit offset.

C:\Program\Git\bin>set TZ=FOO-1

C:\Program\Git\bin>.\date
Mon Feb 15 14:00:29 FOO 2010

C:\Program\Git\bin>set TZ=BAR-1

C:\Program\Git\bin>.\date
Mon Feb 15 14:00:42 BAR 2010

So it seems.

-1 has the correct effect. But Sweden's time is UTC+1: CET on wikipedia

Is there a mismatch in the convention, -1 in TZ is UTC+1?

If I want to let the OS decide if it's summer or winter as indicated in njd's reply, I can omit the start and end time. I suppose the correct string is TZ=CET-1CEST-2, is that correct?

I am not sure what windows does in summertime. If it updates the clock itself, the string above will not work. If it updates the offset only, then this might work. More insights?

share|improve this question
    
The link in my answer (to the GNU libc TZ-Variable page) states: ...The offset specifies the time value one must add to the local time to get a Coordinated Universal Time value. ... This is positive if the local time zone is west of the Prime Meridian and negative if it is east. –  njd Feb 16 '10 at 9:50
    
Agreed. The page says also that if nothing is specified for the summer time, 1 hour ahead of standard is assumed. CET-1CEST must be enough (if the OS deals with the switching dates). –  Gauthier Feb 16 '10 at 12:47
add comment

2 Answers 2

up vote 4 down vote accepted

It looks like the ls command doesn't know enough about European time-zomes and the dates when CEST is in effect.

I'm guessing the 16:01 reported by DIR was 16:01 CEST, but the ls command hasn't applied the extra hour for daylight saving.

I'm not sure how msysgit (or just msys) stores timezone information: in Solaris, there are zoneinfo files for this.

If there's some way of communicating to your msysgit tools when the daylight saving begins and ends, then your ls command could get it right.

Maybe this page offers a clue.
Try playing around with environment settings like

SET TZ=CET+1CEST,M3.5.0/2,M10.5.0/2

which states that CEST begins on the last Sunday (day 0) of March at 2am, and ends on the last Sunday of October at 2am. That should give you something to work with.

(Normally, it would be enough to state the timezone and DST timezone only: "CET+1CEST" and rely on the OS to know what the relevant dates should be. But here we are setting the dates explicitly.)

I can see the something similar happening in reverse with MSys on my system:
A file reported by the DIR command (and Windows Explorer) as written on 2008-04-18 at 12:19 (which should have been BST: GMT+1) is shown by MSys ls as 13:19:06.

If I play around with the timezone dates and SET TZ as though DST did not begin until the end of April, I can change this to match DIR's output.

But as far as I know, the EU-wide rule on Summer-time is that it begins on the last Sunday of March (M3.5.0/2) and ends on the last Sunday of October (M10.5.0/2).

So when I type (in an MSys shell, or in Cygwin, or in Unix):

TZ=GMT0BST,M3.5.0/2,M10.5.0/2 ls --full-time foo

I should see the correct time, with DST applied. In fact I see 13:19, just the same as when I don't set the timezone at all.

Which makes me wonder if MSys and msysgit are getting it right, and Windows is getting it wrong.

share|improve this answer
    
Thanks for the update. I am currently playing with the TZ environment variable, but I am not sure whether git\bin\date.exe uses it. "export" does not work in my DOS prompt. I think CEST should take care of changing to summertime automatically? –  Gauthier Feb 15 '10 at 11:46
    
Sorry, I was thinking of POSIX/Bash syntax. I've corrected my answer, and added a note about the start/end dates. –  njd Feb 15 '10 at 12:10
    
I think this is sorted out now. I'll see in Mars if the change is working. I wonder about the OS knowing the relevant days of change, I have not read it anywhere else? Thanks a lot! –  Gauthier Feb 16 '10 at 6:44
    
For the record: the change to summer time went smooth! –  Gauthier Mar 29 '10 at 12:49
add comment

It's annoying but yes, there's a mismatch in the convention, so for example if your timezone is -3 then you want a +3 in the TZ environment variable. From GNU C library documentation:

The offset specifies the time value you must add to the local time to get a Coordinated Universal Time value. It has syntax like [+|-]hh[:mm[:ss]]. This is positive if the local time zone is west of the Prime Meridian and negative if it is east.

If you do not specify DST period in TZ, the C library assumes there's no DST at all. I think it would be impracticable to rely on each different operating system for providing DST period when missing in TZ. In fact, it would be much easier to just get the local time directly instead. So you must specify DST period when using that specific TZ setting format.

The solution that worked for me was to write a script in Ruby which provides me with the DST period for my country where it is variable over the years. Then it outputs that in proper format for TZ, which is set in my /etc/profile.d/ in MSYS. This is my current TZ value, works just fine for both ls and date:

BRT+3BRST,M10.3.0/0,M2.3.0/0

Note, however, that Microsoft's C runtime is also sensitive to the value of TZ, which may lead to conflicts between MSYS and MSVCRT applications. You need to have TZ unset when running MSVCRT-based applications (such as Python), or some better solution. As for your settings not working, try the exact value above, changing only DST period to match yours.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.