Re: A structured format for dates?

[iain hill <[e-mail]>]

Hello all,

Is using a floating point number based upon a chosen format of Julian 
Date (perhaps beginning at the start of UNIX time) really not worthy of 
more consideration here? This is what professional time keepers use, and 
is infinitely more appropriate for this kind of usage as the exact time 
is always recorded, geographical location information is discarded.

I see now that the format is supposed to record the time of the event of 
the transfer and nothing else, this would insure that all nodes are 
using the same time at the very least, and that is the job of date in 
its essence.

There are two different time types being discussed here, TAI and UTC, 
That these are getting mixed together apparently somewhat unwittingly; 
Might this be the factor at the heart of any discord?

The JD, Julian Date system may be used with TAI, TT, TCB, or UTC. It is 
a perfect compromise between TAI which,  for our intent and purpose, is 
what UNIX time is and UTC, which is what a time with a time zone is.

JD is the standard used in astronomy and chronology, MJD or Modified 
Julian Date is another standard which is commonly used, which is the 
value of JD - 2400000.5 setting the number for more current dates and 
also setting the day change to be midnight and not midday, by way of a 
0.5 day shift.

Kind regards,

Iain.

On 24/08/2022 18:32, Justin Richer wrote:
> +1 to Mark’s arguments, and this is why I’m also in favor of the textual serialization.
>
> It feels like the calls for using an integer serialization are an optimization of something that would be better suited to another format, like binary fields.
>
> For a similar strawman, things like lists and dictionaries could have had more compact serializations (no whitespace, length encoding, etc), but they are instead human-readable structures that are easy to visually parse. That’s what I’d want from a Date field type.
>
> I think the previous PR cut the right balance between having a very precise underlying data model (it’s an integer from epoch) and a human-readable form (a strict serialization and parsing rule set), and kept open the door to the compact optimization that’s being argued for in this thread. I would personally rather we go with that model as opposed to tightly tying together the data model and serialization like is being suggested.
>
>   — Justin
>
>> On Aug 23, 2022, at 11:11 PM, Mark Nottingham <[e-mail]> wrote:
>>
>> Personal response -
>>
>>> On 23 Aug 2022, at 11:27 pm, Tommy Pauly <[e-mail]> wrote:
>>>
>>> The numeric type is not only simpler to process for a computer, but also should be generally smaller on the wire, particularly if we have binary structured fields one day. The scale of that alone can have a great impact.
>> It's important to remember that if/when we have binary structured fields, the binary wire representation can be different from the textual one we're defining now -- for example, it could be the same as that of an integer, but with a different type flag.
>>
>> What we're defining now is merely what the _textual_ (HTTP/1.1-ish) representation of a date is. The underlying data model for dates is separable (see below), as is its mapping to other serialisations of structured types.
>>
>>> I imagine it’s also a lot easier to translate *to* the human readable / localized format for a date from the number, since the number is an unambiguous form. Parsing dates the other way (from human readable to machine readable) is where much of the complexity and ambiguity arises, so a scheme that only requires transformations in one direction seems preferable.
>> That entirely relies upon the precision of the underlying data model and the rules for transforming it to/from the textual representation. In the previous PR, the underlying data model was an integer, and the rules were fairly precise, so I don't think this is a strong reason to go this way.
>>
>> This is why I'm not terribly convinced by the arguments for an integer textual representation so far; I think we can have the best of both worlds (integer data model / human-friendly textual representation) *if* we believe that binary structured fields are going to happen. IMO the only reason we'd choose an integer textual representation is if we didn't believe that.
>>
>> Cheers,
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>