Skip to main content
deleted 52 characters in body; deleted 378 characters in body; deleted 36 characters in body
Source Link
njd
  • 11.3k
  • 3
  • 41
  • 37

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

# Zone  NAME        GMTOFF  RULES   FORMAT  [UNTIL]
Zone Europe/Stockholm   1:12:12 -   LMT 1879 Jan  1
            1:00:14 -   SET 1900 Jan  1 # Swedish Time
            1:00    -   CET 1916 May 14 23:00
            1:00    1:00    CEST    1916 Oct  1 01:00
            1:00    -   CET 1980
            1:00    EU  CE%sT
SET TZ=CET+1CEST,M4M3.15.0/2,M10.5.0/2

which states that CEST begins on the 1stlast Sunday (day 0) of AprilMarch at 2am, and ends on the last Sunday of October at 2am. I don't know if these dates are correct, but it givesThat should give you something to work with.

So I think thatWhich makes me wonder if MSys and msysgit are getting it right, and Windows is getting it wrong by showing the CET time and not adding the extra hour for CEST.

I'm not sure how msysgit (or just msys) stores timezone information: in Solaris, there are zoneinfo files, which contain entries like:

# Zone  NAME        GMTOFF  RULES   FORMAT  [UNTIL]
Zone Europe/Stockholm   1:12:12 -   LMT 1879 Jan  1
            1:00:14 -   SET 1900 Jan  1 # Swedish Time
            1:00    -   CET 1916 May 14 23:00
            1:00    1:00    CEST    1916 Oct  1 01:00
            1:00    -   CET 1980
            1:00    EU  CE%sT
SET TZ=CET+1CEST,M4.1.0/2,M10.5.0/2

which states that CEST begins on the 1st Sunday (day 0) of April at 2am, and ends on the last Sunday of October at 2am. I don't know if these dates are correct, but it gives you something to work with.

So I think that MSys and msysgit are getting it right, and Windows is getting it wrong by showing the CET time and not adding the extra hour for CEST.

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

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.

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

added 964 characters in body; added 13 characters in body
Source Link
njd
  • 11.3k
  • 3
  • 41
  • 37

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, which contain entries like:

# Zone  NAME        GMTOFF  RULES   FORMAT  [UNTIL]
Zone Europe/Stockholm   1:12:12 -   LMT 1879 Jan  1
            1:00:14 -   SET 1900 Jan  1 # Swedish Time
            1:00    -   CET 1916 May 14 23:00
            1:00    1:00    CEST    1916 Oct  1 01:00
            1:00    -   CET 1980
            1:00    EU  CE%sT

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,M4.1.0/2,M10.5.0/2

which states that CEST begins on the 1st Sunday (day 0) of April at 2am, and ends on the last Sunday of October at 2am. I don't know if these dates are correct, but it gives 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.

So I think that MSys and msysgit are getting it right, and Windows is getting it wrong by showing the CET time and not adding the extra hour for CEST.

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, which contain entries like:

# Zone  NAME        GMTOFF  RULES   FORMAT  [UNTIL]
Zone Europe/Stockholm   1:12:12 -   LMT 1879 Jan  1
            1:00:14 -   SET 1900 Jan  1 # Swedish Time
            1:00    -   CET 1916 May 14 23:00
            1:00    1:00    CEST    1916 Oct  1 01:00
            1:00    -   CET 1980
            1:00    EU  CE%sT

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,M4.1.0/2,M10.5.0/2

which states that CEST begins on the 1st Sunday (day 0) of April at 2am, and ends on the last Sunday of October at 2am. I don't know if these dates are correct, but it gives 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.)

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, which contain entries like:

# Zone  NAME        GMTOFF  RULES   FORMAT  [UNTIL]
Zone Europe/Stockholm   1:12:12 -   LMT 1879 Jan  1
            1:00:14 -   SET 1900 Jan  1 # Swedish Time
            1:00    -   CET 1916 May 14 23:00
            1:00    1:00    CEST    1916 Oct  1 01:00
            1:00    -   CET 1980
            1:00    EU  CE%sT

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,M4.1.0/2,M10.5.0/2

which states that CEST begins on the 1st Sunday (day 0) of April at 2am, and ends on the last Sunday of October at 2am. I don't know if these dates are correct, but it gives 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.

So I think that MSys and msysgit are getting it right, and Windows is getting it wrong by showing the CET time and not adding the extra hour for CEST.

deleted 1 characters in body; added 201 characters in body
Source Link
njd
  • 11.3k
  • 3
  • 41
  • 37

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, which contain entries like:

# Zone  NAME        GMTOFF  RULES   FORMAT  [UNTIL]
Zone Europe/Stockholm   1:12:12 -   LMT 1879 Jan  1
            1:00:14 -   SET 1900 Jan  1 # Swedish Time
            1:00    -   CET 1916 May 14 23:00
            1:00    1:00    CEST    1916 Oct  1 01:00
            1:00    -   CET 1980
            1:00    EU  CE%sT

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][1]this page offers a clue.

Try
Try playing around with environment settings like

exportSET TZ='CET+1CESTTZ=CET+1CEST,M4.1.0/2,M10.5.0/2'2

which states that CEST begins on the 1st Sunday (day 0) of April at 2am, and ends on the last Sunday of October at 2am. I don't know if these dates are correct, but it gives you something to work with. [1]

(Normally, it would be enough to state the timezone and DST timezone only: http://www.gnu.org/s/libc/manual/html_node/TZ-Variable.html"CET+1CEST" and rely on the OS to know what the relevant dates should be. But here we are setting the dates explicitly.)

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, which contain entries like:

# Zone  NAME        GMTOFF  RULES   FORMAT  [UNTIL]
Zone Europe/Stockholm   1:12:12 -   LMT 1879 Jan  1
            1:00:14 -   SET 1900 Jan  1 # Swedish Time
            1:00    -   CET 1916 May 14 23:00
            1:00    1:00    CEST    1916 Oct  1 01:00
            1:00    -   CET 1980
            1:00    EU  CE%sT

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][1] offers a clue.

Try playing around with environment settings like

export TZ='CET+1CEST,M4.1.0/2,M10.5.0/2'

which states that CEST begins on the 1st Sunday (day 0) of April at 2am, and ends on the last Sunday of October at 2am. I don't know if these dates are correct, but it gives you something to work with. [1]: http://www.gnu.org/s/libc/manual/html_node/TZ-Variable.html

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, which contain entries like:

# Zone  NAME        GMTOFF  RULES   FORMAT  [UNTIL]
Zone Europe/Stockholm   1:12:12 -   LMT 1879 Jan  1
            1:00:14 -   SET 1900 Jan  1 # Swedish Time
            1:00    -   CET 1916 May 14 23:00
            1:00    1:00    CEST    1916 Oct  1 01:00
            1:00    -   CET 1980
            1:00    EU  CE%sT

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,M4.1.0/2,M10.5.0/2

which states that CEST begins on the 1st Sunday (day 0) of April at 2am, and ends on the last Sunday of October at 2am. I don't know if these dates are correct, but it gives 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.)

added 300 characters in body
Source Link
njd
  • 11.3k
  • 3
  • 41
  • 37
Loading
added 755 characters in body
Source Link
njd
  • 11.3k
  • 3
  • 41
  • 37
Loading
Source Link
njd
  • 11.3k
  • 3
  • 41
  • 37
Loading