mirror of
https://github.com/rkd77/elinks.git
synced 2024-09-18 01:26:23 -04:00
5a43c55c9e
Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime. |
||
|---|---|---|
| .. | ||
| auth | ||
| bittorrent | ||
| file | ||
| finger | ||
| fsp | ||
| ftp | ||
| gopher | ||
| http | ||
| nntp | ||
| rewrite | ||
| smb | ||
| test | ||
| about.c | ||
| about.h | ||
| common.c | ||
| common.h | ||
| data.c | ||
| data.h | ||
| date.c | ||
| date.h | ||
| header.c | ||
| header.h | ||
| Makefile | ||
| protocol.c | ||
| protocol.h | ||
| proxy.c | ||
| proxy.h | ||
| README.timegm | ||
| uri.c | ||
| uri.h | ||
| user.c | ||
| user.h | ||
This file contains description of our my_timegm() function in date.c. It was
posted as a mail to links-list by Stephane Chazelas, and I thought it may be
interesting for someone, so I decided to include it in the ELinks distribution.
Un explanation for it as one (me to start with) may wonder why
this works.
We first change of calendar. To make things easy, let's say
that 0/0/0 0:0:0 in our new calendar is the Marsh 1st 1968, so
just after a february 29th as 1968 was a leap year.
if y/m/d h:min:s is time in our calendar
and
Y/M/D h:min:s in the new calendar
M = m - 1 - 2 (+ 12 if m < 3)
Y = y - 68 (-1 if m < 3)
D = d - 1
at Y/0/0 0:0:0, there has been Y / 4 leap years in the past, so
(int) 365 * Y + Y / 4 days have past.
at Y/M/0 0:0:0, lets find how many days have past since Y/0/0:
|Mar Feb
M| 0 1 2 3 4 5 6 7 8 9 10 11
-------------------+-----------------------------------------------
days in that month|31 30 31 30 31 31 30 31 30 31 31 28 or 29
-------------------+-----------------------------------------------
x = days at Y/M/0| 0 31 61 92 122 153 184 214 245 275 306 337
-------------------+-----------------------------------------------
first approximation|
y = 30 * M| 0 30 60 90 120 150 180 210 240 270 300 330
-------------------+-----------------------------------------------
x - y| 0 1 1 2 2 3 4 4 5 5 6 7
-------------------+-----------------------------------------------
(M + 4) * 3 / 5 - 2| 0 1 1 2 2 3 4 4 5 5 6 7
-------------------+-----------------------------------------------
x - y = (M + 4) * 3 / 5 - 2
x = 30 * M + (M + 4) * 3 / 5 - 2
x = (153 * M + 2) / 5
So at Y/M/D 0:0:0,
Y * 1461 / 4 + (153 * M + 2) / 5 + D days have past since
the 1st of March of 1968
1st of March of 1968 was 671 days before 1970 Jan 1st (year 0
for unix time())
So
t = s + 60 * (min + 60 * (h + 24 * (Y * 1461 / 4 + (153 * M + 2) / 5 + D - 671)))
t = s + 60 * (min + 60 * (h + 24 * (Y * 1461 / 4 + (153 * M + 2) / 5 + d - 672)))
This shouldn't work past 2100/02/28 23:59:59 as 2100 is not a leap year.
--
St<53>phane