I still have this todo item:
On 12/30/2016 11:28 AM, darken wrote:
> I've seen a value of "18446744072363093454" for stat %Z (seconds since
> epoch), for some files on a users device (Android 6.01).
To which Elliot replied with:
On 12/30/2016 01:39 PM, enh wrote:
> time_t on 32-bit Android is 32
On 01/25/2017 06:25 PM, Rich Felker wrote:
>> According to man 2 time:
>>
>> time() returns the time as the number of seconds since the Epoch,
>> 1970-01-01 00:00:00 + (UTC).
>>
>> I.E. the definition of unix time is UTC. So %s _not_ being UTC is silly.
>
> Nobody is questioning whethe
On Wed, Jan 25, 2017 at 05:15:37PM -0600, Rob Landley wrote:
> On 01/24/2017 06:10 PM, Rich Felker wrote:
> >>> strptime with %s? I suspect there are some nasty underspecified issues
> >>> with how it interacts with timezones.
> >>
> >> I thought unix time was always UTS and the timezone just affec
On Wed, 25 Jan 2017 17:15:37 -0600 Rob Landley wrote:
> On 01/24/2017 06:10 PM, Rich Felker wrote:
> >>> strptime with %s? I suspect there are some nasty underspecified
> >>> issues with how it interacts with timezones.
> >>
> >> I thought unix time was always UTS and the timezone just affected
>
On 01/24/2017 06:10 PM, Rich Felker wrote:
>>> strptime with %s? I suspect there are some nasty underspecified issues
>>> with how it interacts with timezones.
>>
>> I thought unix time was always UTS and the timezone just affected how it
>> was displayed?
>
> The problem is that strptime produces
On Tue, Jan 24, 2017 at 05:47:46PM -0600, Rob Landley wrote:
>
>
> On 01/21/2017 06:25 PM, Rich Felker wrote:
> > On Sat, Jan 21, 2017 at 03:18:28PM -0600, Rob Landley wrote:
> >>> Or if it's signed, that's -1346458162 which would be... sometime in the
> >>> 1930's? hmmm... "./date -D %s -d -1346
On Tue, Jan 24, 2017 at 3:47 PM, Rob Landley wrote:
>
>
> On 01/21/2017 06:25 PM, Rich Felker wrote:
>> On Sat, Jan 21, 2017 at 03:18:28PM -0600, Rob Landley wrote:
Or if it's signed, that's -1346458162 which would be... sometime in the
1930's? hmmm... "./date -D %s -d -1346458162" is fa
On 01/21/2017 06:25 PM, Rich Felker wrote:
> On Sat, Jan 21, 2017 at 03:18:28PM -0600, Rob Landley wrote:
>>> Or if it's signed, that's -1346458162 which would be... sometime in the
>>> 1930's? hmmm... "./date -D %s -d -1346458162" is failing under glibc,
>>> and failing _differently_ under musl.
On Sat, Jan 21, 2017 at 03:18:28PM -0600, Rob Landley wrote:
> > Or if it's signed, that's -1346458162 which would be... sometime in the
> > 1930's? hmmm... "./date -D %s -d -1346458162" is failing under glibc,
> > and failing _differently_ under musl. (Wheee.)
> >
> > /me goes down tangent rathol
On 12/30/2016 04:01 PM, enh wrote:
> On Fri, Dec 30, 2016 at 1:51 PM, Rob Landley wrote:
>> On 12/30/2016 01:39 PM, enh wrote:
>>> 1928-04-26 17:31:55.746667836 18446744072394174731
>>
>> Really we can partially blame posix here for not specifying whether
>> time_t is signed or unsigned. (If it's
On Fri, Dec 30, 2016 at 1:51 PM, Rob Landley wrote:
> On 12/30/2016 01:39 PM, enh wrote:
>> 1928-04-26 17:31:55.746667836 18446744072394174731
>
> Really we can partially blame posix here for not specifying whether
> time_t is signed or unsigned. (If it's unsigned it can't represent times
> before
On Fri, Dec 30, 2016 at 1:44 PM, Rob Landley wrote:
> I have negotiated a 3 day weekend for the holidays! Starting today. Ok,
> catching up...
>
> On 12/30/2016 01:39 PM, enh wrote:
>> time_t on 32-bit Android is 32 bits.
>>
>> that particular value looks like a sign-extension of 0xAFBEADCE, which
On 12/30/2016 01:39 PM, enh wrote:
> 1928-04-26 17:31:55.746667836 18446744072394174731
Really we can partially blame posix here for not specifying whether
time_t is signed or unsigned. (If it's unsigned it can't represent times
before January 1, 1970, as the code on the left is doing. And there
_
I have negotiated a 3 day weekend for the holidays! Starting today. Ok,
catching up...
On 12/30/2016 01:39 PM, enh wrote:
> time_t on 32-bit Android is 32 bits.
>
> that particular value looks like a sign-extension of 0xAFBEADCE, which
> is still some time in 2063.
Or if it's signed, that's -134
time_t on 32-bit Android is 32 bits.
that particular value looks like a sign-extension of 0xAFBEADCE, which
is still some time in 2063. (so i'd assume this device's clock is set
wrong, and i'd assume -- since this is presumably a 32-bit device with
a signed 32-bit time_t -- that that's going to be
15 matches
Mail list logo