[saga-rg] Timestamp issue

[Andre Merzky]

Hi Mark, Pascal, 

I think what the underlying MW is using does not matter too
much, as mapping is straight forward, and the API should use
what is most comfortable to the developer/user, not for the
implementor of the API.  Having said that, the scheme you
list below looks just as nice as the others you listed
earlier :-)

Proposal:

  - allow time from epoch (as that is easy to obtain/use on
    programming level in most languages/OSs)

  - allow the proposed constructs, as below

      2003-12-13T18:30:02Z
      2003-12-13T18:30:02.25Z
      2003-12-13T18:30:02+01:00
      2003-12-13T18:30:02.25+01:00

    but allow to add spaces, and to replace the T with a
    space, like:
    
      2003-12-13 18:30:02 Z
      2003-12-13 18:30:02.25 Z
      2003-12-13 18:30:02    +01:00
      2003-12-13 18:30:02.25 +01:00

    An implementation can easily map that to the standard
    forms, with

      $date =~ s/ (\S{10})    \s+ (.+) / $1T$2 / x;
      $date =~ s/ (\S{19,22}) \s+ (.+) / $1 $2 / x;

That would pose small overhead to the implementation
(conversion is well defined, and straight forward), stays
human readable, allows to use the standard representations,
and allows the epoch, as thta is widely used.

Does that make sense, or would that be too loosely defined?

Cheers, Andre.


Quoting [Mark Mc Keown] (Jun 12 2006):
> 
> Hi Andre
> 
> > Wow!  you are thorough! :-)  Thanks!
> 
> Unfortuntely I wasn't thorough enough, I didn't include
> xsd:DateTime which is what much of the underlying middleware
> will be using.
> 
> For a description of the issues related to timestamps and
> standards check out the following thread on the Atom mailing 
> list:
> 
> http://www.imc.org/atom-syntax/mail-archive/msg13103.html
> 
> I think the solution that the Atom people came up with
> is a good compromise as it is complient with xsd:DateTime,
> ISO 8601, RFC 3339 and the W3C profile of ISO 8601:
> 
> >>>
> 
> 3.3.  Date Constructs
> 
>    A Date construct is an element whose content MUST conform to the
>    "date-time" production in [RFC3339].  In addition, an uppercase "T"
>    character MUST be used to separate date and time, and an uppercase
>    "Z" character MUST be present in the absence of a numeric time zone
>    offset.
> 
>    atomDateConstruct =
>       atomCommonAttributes,
>       xsd:dateTime
> 
>    Such date values happen to be compatible with the following
>    specifications: [ISO.8601.1988], [W3C.NOTE-datetime-19980827], and
>    [W3C.REC-xmlschema-2-20041028].
> 
>    Example Date constructs:
> 
>    <updated>2003-12-13T18:30:02Z</updated>
>    <updated>2003-12-13T18:30:02.25Z</updated>
>    <updated>2003-12-13T18:30:02+01:00</updated>
>    <updated>2003-12-13T18:30:02.25+01:00</updated>
> 
>    Date values SHOULD be as accurate as possible.  For example, it would
>    be generally inappropriate for a publishing system to apply the same
>    timestamp to several entries that were published during the course of
>    a single day.
> 

> <<<
> 
> The above is from RFC 4287, http://www.ietf.org/rfc/rfc4287.txt
> 
> I am not fully clued up on what SAGA is doing but you could include
> a helper function that would convert the above DateTime into seconds 
> from the epoch. 
> 
> cheers
> Mark
> 
> 
> 
> 
> > 
> > Seems that w3 has a similar convention as the ISO standard
> > Chris referred to.  
> > 
> > Well, what was that famous quote again: "The nice thing
> > about standards is that there are so many to choose from"
> > ;-)
> > 
> > Do you, or Chris, or others, have any opinion which version
> > we should use?
> > 
> > I personally think that the ISO and W3 one are not looking
> > particularily beautiful, with T (!) as a delimiter, but they
> > are surely simple enough to parse...
> > 
> > On the other we try to stay close to POSIX in many places,
> > so sticking with ctime, or even seconds since epoch, would
> > also be well justified...
> > 
> > Cheers, Andre.
> > 
> > 
> > 
> > Quoting [Mark.McKeown at manchester.ac.uk] (May 17 2006):
> > > 
> > > The W3C has a profile of ISO 8601 which simplifies life:
> > > 
> > > http://www.w3.org/TR/NOTE-datetime
> > > 
> > > Also IETF have a RFC "Date and Time on the
> > > Internet: Timestamps":
> > > 
> > > http://www.faqs.org/rfcs/rfc3339.html
> > > 
> > > Other Relevent standards that specify dates are:
> > > 
> > > RFC 822 and RFC 1123
> > > 
> > > The HTTP protocol accepts dates in a number of formats,
> > > from section 3.3.1:
> > > 
> > > "HTTP applications have historically allowed three different formats
> > >  for the representation of date/time stamps:
> > > 
> > >       Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
> > >       Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
> > >       Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format"
> > > 
> > > 
> > > Hope this helps
> > > Mark
> > > 
> > > >
> > > >>Quoting [Christopher Smith] (May 05 2006):
> > > >>>
> > > >>>Does anybody have a pointer to the relevant ISO standard?
> > > >>
> > > >>Is there an ISO standard for that?
> > > >>
> > > >I found this link:
> > > >
> > > >http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html
> > > >
> > > >but I haven't read it in any detail.
> > > >
> > > >-- Chris
> > > >
> > > >
> > > >
> > 
> > 
> > 
> > 



-- 
"So much time, so little to do..."  -- Garfield