You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// BooleanType is special: its bit-width is not the size of the primitive type, and its `index`
40
43
// operation assumes bit-packing.
41
44
/// A boolean datatype
@@ -218,84 +221,19 @@ make_type!(
218
221
IntervalYearMonthType,
219
222
i32,
220
223
DataType::Interval(IntervalUnit::YearMonth),
221
-
"A “calendar” interval stored as the number of whole months."
224
+
"A 32-bit “calendar” interval type representing the number of whole months."
222
225
);
223
226
make_type!(
224
227
IntervalDayTimeType,
225
228
IntervalDayTime,
226
229
DataType::Interval(IntervalUnit::DayTime),
227
-
r#"A “calendar” interval type in days and milliseconds.
228
-
229
-
## Representation
230
-
This type is stored as a single 64 bit integer, interpreted as two i32 fields:
231
-
1. the number of elapsed days
232
-
2. The number of milliseconds (no leap seconds),
233
-
234
-
```text
235
-
┌──────────────┬──────────────┐
236
-
│ Days │ Milliseconds │
237
-
│ (32 bits) │ (32 bits) │
238
-
└──────────────┴──────────────┘
239
-
0 31 63 bit offset
240
-
```
241
-
Please see the [Arrow Spec](https://github.com/apache/arrow/blob/081b4022fe6f659d8765efc82b3f4787c5039e3c/format/Schema.fbs#L406-L408) for more details
242
-
243
-
## Note on Comparing and Ordering for Calendar Types
244
-
245
-
Values of `IntervalDayTimeType` are compared using their binary representation,
246
-
which can lead to surprising results. Please see the description of ordering on
247
-
[`IntervalMonthDayNanoType`] for more details
248
-
"#
230
+
"A “calendar” interval type representing days and milliseconds. See [`IntervalDayTime`] for more details."
249
231
);
250
232
make_type!(
251
233
IntervalMonthDayNanoType,
252
234
IntervalMonthDayNano,
253
235
DataType::Interval(IntervalUnit::MonthDayNano),
254
-
r#"A “calendar” interval type in months, days, and nanoseconds.
255
-
256
-
## Representation
257
-
This type is stored as a single 128 bit integer,
258
-
interpreted as three different signed integral fields:
259
-
260
-
1. The number of months (32 bits)
261
-
2. The number days (32 bits)
262
-
2. The number of nanoseconds (64 bits).
263
-
264
-
Nanoseconds does not allow for leap seconds.
265
-
Each field is independent (e.g. there is no constraint that the quantity of
266
-
nanoseconds represents less than a day's worth of time).
Please see the [Arrow Spec](https://github.com/apache/arrow/blob/081b4022fe6f659d8765efc82b3f4787c5039e3c/format/Schema.fbs#L409-L415) for more details
276
-
277
-
## Note on Comparing and Ordering for Calendar Types
278
-
Values of `IntervalMonthDayNanoType` are compared using their binary representation,
279
-
which can lead to surprising results.
280
-
281
-
Spans of time measured in calendar units are not fixed in absolute size (e.g.
282
-
number of seconds) which makes defining comparisons and ordering non trivial.
283
-
For example `1 month` is 28 days for February but `1 month` is 31 days
284
-
in December.
285
-
286
-
This makes the seemingly simple operation of comparing two intervals
287
-
complicated in practice. For example is `1 month` more or less than `30 days`? The
288
-
answer depends on what month you are talking about.
289
-
290
-
This crate defines comparisons for calendar types using their binary
291
-
representation which is fast and efficient, but leads
292
-
to potentially surprising results.
293
-
294
-
For example a
295
-
`IntervalMonthDayNano` of `1 month` will compare as **greater** than a
296
-
`IntervalMonthDayNano` of `100 days` because the binary representation of `1 month`
297
-
is larger than the binary representation of 100 days.
298
-
"#
236
+
r"A “calendar” interval type representing months, days, and nanoseconds. See [`IntervalMonthDayNano`] for more details."
/// Please see the [Arrow Spec](https://github.com/apache/arrow/blob/081b4022fe6f659d8765efc82b3f4787c5039e3c/format/Schema.fbs#L409-L415) for more details
45
+
///
46
+
///## Note on Comparing and Ordering for Calendar Types
47
+
///
48
+
/// Values of `IntervalMonthDayNano` are compared using their binary
49
+
/// representation, which can lead to surprising results.
50
+
///
51
+
/// Spans of time measured in calendar units are not fixed in absolute size (e.g.
52
+
/// number of seconds) which makes defining comparisons and ordering non trivial.
53
+
/// For example `1 month` is 28 days for February but `1 month` is 31 days
54
+
/// in December.
55
+
///
56
+
/// This makes the seemingly simple operation of comparing two intervals
57
+
/// complicated in practice. For example is `1 month` more or less than `30
58
+
/// days`? The answer depends on what month you are talking about.
59
+
///
60
+
/// This crate defines comparisons for calendar types using their binary
61
+
/// representation which is fast and efficient, but leads
62
+
/// to potentially surprising results.
63
+
///
64
+
/// For example a
65
+
/// `IntervalMonthDayNano` of `1 month` will compare as **greater** than a
66
+
/// `IntervalMonthDayNano` of `100 days` because the binary representation of `1 month`
67
+
/// is larger than the binary representation of 100 days.
/// This type is stored as a single 64 bit integer, interpreted as two i32
325
+
/// fields:
326
+
///
327
+
/// 1. the number of elapsed days
328
+
/// 2. The number of milliseconds (no leap seconds),
329
+
///
330
+
/// ```text
331
+
/// ┌──────────────┬──────────────┐
332
+
/// │ Days │ Milliseconds │
333
+
/// │ (32 bits) │ (32 bits) │
334
+
/// └──────────────┴──────────────┘
335
+
/// 0 31 63 bit offset
336
+
/// ```
337
+
///
338
+
/// Please see the [Arrow Spec](https://github.com/apache/arrow/blob/081b4022fe6f659d8765efc82b3f4787c5039e3c/format/Schema.fbs#L406-L408) for more details
339
+
///
340
+
/// ## Note on Comparing and Ordering for Calendar Types
341
+
///
342
+
/// Values of `IntervalDayTime` are compared using their binary representation,
343
+
/// which can lead to surprising results. Please see the description of ordering on
0 commit comments