|
|
specs.txt - sfeed_tests - sfeed tests and RSS and Atom files |
|
|
 |
git clone git://git.codemadness.org/sfeed_tests (git://git.codemadness.org) |
|
|
 |
Log |
|
|
|
Files |
|
|
|
Refs |
|
|
|
README |
|
|
|
LICENSE |
|
|
|
--- |
|
|
|
specs.txt (2775B) |
|
|
|
--- |
|
|
|
1 Links to specs |
|
|
|
2 -------------- |
|
|
|
3 |
|
|
|
4 - Atom |
|
|
|
5 https://datatracker.ietf.org/doc/html/rfc4287 |
|
|
|
6 |
|
|
|
7 - RSS 0.9, 2.0 and 1.0 |
|
|
|
8 https://www.rssboard.org/rss-specification |
|
|
|
9 |
|
|
|
10 - Dublin Core and RDF |
|
|
|
11 https://www.dublincore.org/specifications/dublin-core/dcmi-terms/ |
|
|
|
12 https://web.resource.org/rss/1.0/modules/dc/ |
|
|
|
13 |
|
|
|
14 - Media RSS (MRSS) |
|
|
|
15 https://www.rssboard.org/media-rss |
|
|
|
16 |
|
|
|
17 - OPML |
|
|
|
18 https://en.wikipedia.org/wiki/OPML |
|
|
|
19 http://opml.org/ |
|
|
|
20 |
|
|
|
21 |
|
|
|
22 Time formats: |
|
|
|
23 |
|
|
|
24 - RFC3339 Date and Time on the Internet: Timestamps: |
|
|
|
25 https://www.rfc-editor.org/rfc/rfc3339 |
|
|
|
26 |
|
|
|
27 - RFC822: |
|
|
|
28 https://www.rfc-editor.org/rfc/rfc822 |
|
|
|
29 5. Date and Time Specification |
|
|
|
30 |
|
|
|
31 - RFC822 obsoleted by RFC2822: |
|
|
|
32 https://www.rfc-editor.org/rfc/rfc2822 |
|
|
|
33 |
|
|
|
34 - ISO 8601-1: |
|
|
|
35 https://en.wikipedia.org/wiki/ISO_8601 |
|
|
|
36 There might be some free and open resource someplace... |
|
|
|
37 |
|
|
|
38 |
|
|
|
39 Some notes about specs |
|
|
|
40 ---------------------- |
|
|
|
41 |
|
|
|
42 - ISO 8601-1 needs to be bought to see it. It is not free as in cost. |
|
|
|
43 |
|
|
|
44 - RFC822 incorrectly defined military timezones. Mentioned in its succesor RFC2822: |
|
|
|
45 " The 1 character military time zones were defined in a non-standard |
|
|
|
46 way in [RFC822] and are therefore unpredictable in their meaning. |
|
|
|
47 The original definitions of the military zones "A" through "I" are |
|
|
|
48 equivalent to "+0100" through "+0900" respectively; "K", "L", and "M" |
|
|
|
49 are equivalent to "+1000", "+1100", and "+1200" respectively; "N" |
|
|
|
50 through "Y" are equivalent to "-0100" through "-1200" respectively; |
|
|
|
51 and "Z" is equivalent to "+0000". However, because of the error in |
|
|
|
52 [RFC822], they SHOULD all be considered equivalent to "-0000" unless |
|
|
|
53 there is out-of-band information confirming their meaning." |
|
|
|
54 |
|
|
|
55 sfeed does not support military timezones anymore. I haven't noticed any |
|
|
|
56 feeds that use them (apart from Z) anyway. |
|
|
|
57 |
|
|
|
58 - RFC822 only defines American timezone names (so "CEST" is not supported). |
|
|
|
59 |
|
|
|
60 - RFC2822 defines leap seconds are allowed (23:59:60). |
|
|
|
61 |
|
|
|
62 - Second fractions are allowed. sfeed truncates them. |
|
|
|
63 |
|
|
|
64 - Timezones can be in the range: -9959 through +9959. sfeed allows -9999 through -9999. |
|
|
|
65 |
|
|
|
66 - time_t is typically signed 64-bit on platforms. POSIX defines it simply as an |
|
|
|
67 integer (not clear if signed or unsigned). |
|
|
|
68 |
|
|
|
69 Many 32-bit platforms use a signed 32-bit long for time_t. |
|
|
|
70 Open Watcom uses a 32-bit unsigned long for time_t. |
|
|
|
71 "long long" is a datatype defines as at least 64-bit. |
|
|
|
72 The sfeed parser consistently parses it to a signed 64-bit number (long long). |
|
|
|
73 |
|
|
|
74 The format tools read this number and convert it to a time_t. Depending on |
|
|
|
75 the platform and the time (mostly before 1970 or after 2038) this may |
|
|
|
76 incorrectly wrap the number. |
|
|
|
77 |
|
|
|
78 - There were/are many bugs in time parsing implementations in the different |
|
|
|
79 libcs in various platforms sfeed has a parser for most of the formats used by |
|
|
|
80 RSS/Atom/etc and handles timezone offsets. |
|