News for hackers. Stuff that matters.
Re:HTTP GZIP Compression remote date and time leak by bentronic on Monday February 22, 2016 @06:05AM (#11149987)
Those servers are out of spec, then. The RFC says it's supposed to be POSIX time, i.e., always in UTC. https://tools.ietf.org/html/rfc1952
Re:HTTP GZIP Compression remote date and time leak by joosters on Monday February 22, 2016 @06:17AM (#11150028)
Perhaps those servers are running Windows, where the time is local time and the server doesn't want to spend the effort to do the conversion?
Re:HTTP GZIP Compression remote date and time leak by MichaelBurge on Monday February 22, 2016 @06:22AM (#11150054)
The spec predicted in 1996 that this would happen: "(Note that this may cause problems for MS-DOS and other systems that use local rather than Universal time.)"
Re:HTTP GZIP Compression remote date and time leak by nbevans on Monday February 22, 2016 @09:35AM (#11150996)
Are you seriously suggesting Windows doesn't know the concept of UTC time? And secondly suggesting that fiddling with timezone offsets is an expensive conversion?
Re:HTTP GZIP Compression remote date and time leak by throwaway2048 on Monday February 22, 2016 @01:35PM (#11153115)
the system clock on windows is not UTC, it is local time. On Unix the clock is always UTC and is converted to local time for display purposes.
Re:HTTP GZIP Compression remote date and time leak by nbevans on Monday February 22, 2016 @03:30PM (#11154029)
That is the same as Windows. Where are you getting your information?
Re:HTTP GZIP Compression remote date and time leak by feld on Monday February 22, 2016 @04:00PM (#11154242)
No, there was a time when Windows stored local time -- also synced to BIOS clock. I don't think that's true anymore, though.
Re:HTTP GZIP Compression remote date and time leak by throwaway2048 on Tuesday February 23, 2016 @02:51AM (#11157269)
it remains true in windows 10, although it can be changed via some registry fudging.