Re: Summary of the 2038 BoF at DC17

2017-09-21 Thread Guillem Jover
On Mon, 2017-09-18 at 18:33:12 +0100, Steve McIntyre wrote: > On Mon, Sep 18, 2017 at 05:46:34PM +0100, Ian Jackson wrote: > >Steve McIntyre writes ("Re: Summary of the 2038 BoF at DC17"): > >> It depends on how/where/why you're embedding 64-bit time, > >&g

Re: Summary of the 2038 BoF at DC17

2017-09-18 Thread Steve McIntyre
On Mon, Sep 18, 2017 at 05:46:34PM +0100, Ian Jackson wrote: >Steve McIntyre writes ("Re: Summary of the 2038 BoF at DC17"): >> It depends on how/where/why you're embedding 64-bit time, >> basically. If you're embedding a time_t (or a struct including a >>

Re: Summary of the 2038 BoF at DC17

2017-09-18 Thread Ian Jackson
Steve McIntyre writes ("Re: Summary of the 2038 BoF at DC17"): > It depends on how/where/why you're embedding 64-bit time, > basically. If you're embedding a time_t (or a struct including a > time_t) in your ABI and want to keep to something similar, it's worth &

Re: Summary of the 2038 BoF at DC17

2017-09-18 Thread Steve McIntyre
In article <10e4fa4a-433c-a43b-1136-984293497...@p10link.net> you write: >> Firstly: developers trying to be *too* clever are likely to only make >> things worse - don't do it! Whatever you do in your code, don't bodge >> around the 32-bit time_t problem. *Don't* store time values in weird >> forma

Re: Summary of the 2038 BoF at DC17

2017-09-17 Thread peter green
Firstly: developers trying to be *too* clever are likely to only make things worse - don't do it! Whatever you do in your code, don't bodge around the 32-bit time_t problem. *Don't* store time values in weird formats, and don't assume things about it to "avoid" porting problems. These are all goin

Re: Summary of the 2038 BoF at DC17

2017-09-02 Thread Adam Borowski
On Sat, Sep 02, 2017 at 05:41:09PM +0100, Ben Hutchings wrote: > On Sat, 2017-09-02 at 04:04 +0200, Adam Borowski wrote: > > On Sat, Sep 02, 2017 at 12:58:54AM +0100, Steve McIntyre wrote: > > > UNIX time_t is 31 bits (signed), counting seconds since Jan 1, > > > 1970. It's going to wrap.. It's use

Re: Summary of the 2038 BoF at DC17

2017-09-02 Thread Ben Hutchings
On Sat, 2017-09-02 at 04:04 +0200, Adam Borowski wrote: > On Sat, Sep 02, 2017 at 12:58:54AM +0100, Steve McIntyre wrote: > > What's the problem? > > --- > > > > UNIX time_t is 31 bits (signed), counting seconds since Jan 1, > > 1970. It's going to wrap.. It's used *everywhere* in

Re: Summary of the 2038 BoF at DC17

2017-09-01 Thread Adam Borowski
On Sat, Sep 02, 2017 at 12:58:54AM +0100, Steve McIntyre wrote: > What's the problem? > --- > > UNIX time_t is 31 bits (signed), counting seconds since Jan 1, > 1970. It's going to wrap.. It's used *everywhere* in UNIX-based > systems. Imagine the effects of Y2K, but worse. > Glib

Re: Summary of the 2038 BoF at DC17

2017-09-01 Thread Henrique de Moraes Holschuh
On Sat, 02 Sep 2017, Steve McIntyre wrote: > Massive numbers of libraries are going to need updates, possibly more > than people realise. Anything embedding a time_t will obviously need > changing. However, many more structures will embed a timeval or > timespec and they're also broken. Almost anyt

Summary of the 2038 BoF at DC17

2017-09-01 Thread Steve McIntyre
Hi folks, As promised, here's a quick summary of what was discussed at the 2038 BoF session I ran in Montréal. Thanks to the awesome efforts of our video team, the session is already online [1]. I've taken a copy of the Gobby notes too, alongside my small set of slides for the session. [2] We ha