in the Tmd struct:
>vlongabs; /* seconds since Jan 1 1970, GMT */
in the description of tmtime():
> Tmtime converts the millisecond-resolution timestamp 'abs'
> into a Tm struct in the requested timezone.
the example:
> if(tmtime(&there, here
> Time zones are loaded by as name.
Extra word?
On Sat, Apr 25, 2020, at 8:54 PM, o...@eigenstate.org wrote:
> Date handling on plan 9 is almost adequate today if you don't
> have to parse dates or deal with timezones, and don't do
> multithreading. Otherwise, it's difficult to get right, and
> Just out of curiosity (I may have missed the point): since this is not
> heavily system dependent, and more user related, and for the sake of
> APE, did you consider the standard C and the POSIX interfaces?
First, the posix interfaces share inadequacies with plan 9.
They only work for local time
Hello,
On Sat, Apr 25, 2020 at 05:54:30PM -0700, o...@eigenstate.org wrote:
> Date handling on plan 9 is almost adequate today if you don't
> have to parse dates or deal with timezones, and don't do
> multithreading. Otherwise, it's difficult to get right, and
> we often don't.
>
> We've got a cr
Date handling on plan 9 is almost adequate today if you don't
have to parse dates or deal with timezones, and don't do
multithreading. Otherwise, it's difficult to get right, and
we often don't.
We've got a crappy home-rolled date parser in seconds(1),
a few in the upas source tree to deal with ma
I run a venti from plan9port under Linux at home. Sometimes, typically
after a massive insert, I notice that venti reads and writes about 5 Mb/s
on the index disk continuously. This continues long after the insert has
finished, and there is a marked performance drop. I have never had the
patience t
