iron@... [mailto:iron@...] wrote:
> The time zone doesn't matter because all events are in the
> local time of their location, and 99% of the events will be
> in one time zone. So no, it's not UTC, but I don't care if
> YAML assumes it is as long as YAML doesn't try to adjust it.
The whole point of UTC is that you don't need to adjust it, though you may
have a problem when you emit the times in the local time zone. The "proper"
way for you is probably to store the dates at your local time zone, whatever
Alternatively you could use two fields - one specifying the date (a YAML
timestamp - stored in your DB as just a date, no problem there) and one
specifying the time in that date (a timeperiod, relative to 00:00:00 in that
day according to the current time zone in that day). The second one is
optional (if time is unknown or irrelevant - whole day event).
> On Tue, Sep 03, 2002 at 11:46:00PM +0300, Oren Ben-Kiki wrote:
> > Right. But it isn't that much of a bother however (just a few more
> > characters):
> > Date: 2002-09-02 13:15:00 Z
> Date: !!mx.DateTime '2002-09-02 13:15'
> It's not too much of a bother, but it looks weird to a human
> editing the file who expects to see a normal-looking date and
> time, with no more precision than necessary for the problem domain.
Well, too much precision is one thing, and having an explicit type
annotation is another - I think.
> > The alternative is to allow all sort of shorthands: ...
> I could use all of them. Not in this application, but in one
> with monthly entries, only the year/month would make sense.
> However, I don't necessarily think YAML has to go that far.
> The first two at least cannot be recognized as dates without
> a lot of other non-date fields being mistaken for dates.
Right. That's one reason why we use the "full" notation.
> I don't expect there to be a null time. That's why I'm
> deciding whether I can use a combined date/time field or not.
> My data does have null
> time: it means the date is known but the time isn't, so just
> print the date.
So, do you have a null time or don't you? :-)
> > I'm worried about the fact that there are useful data
> > models that make
> > use of "time of day" without regard to any time zone. Maybe
> > we should
> > reconsider having a "time of day" data type after all. Let's see...
> > - Rename 'time' to 'timestamp'. As you point out above,
> > this clarifies the intent.
> It's already called timestamp in PyYAML.
Right, but the spec doesn't, and it should - regardless of having a
'timeperiod' type or whatever.
> > - Add a 'timeperiod' type (format:
> > [0-9][0-9]:[0-9][0-9]:[0-9][0-9](\.[0-9]*)?).
Probably [0-9]+:[0-9][0-9]:[0-9][0-9](\.[0-9]*)? I think.
> > - The semantics would be "an amount of time relative to some
> > timestamp".
> Well, not necessarily relative to a timestamp. 00:03:00 is
> valid as the time it takes to cook an egg regardless of when
> you started.
No, it fits the definition; "when you started" is the timestamp. Likewise:
> Not all uses of this would be "periods", however. A wakeup
> time of 07:00:00 is not a period, it's a point in time on a
> 24-hour clock.
The timestamp is 00:00:00 of that day (in the local time zone).
> We'd just have to mention this in the docs,
> that "timeperiod" is also useful with points in time.
I don't think so. It is always relative to some point in time (an implicitly
defined point to be sure, but still a well-defined point in time).
> Of course, the seconds portion should be optional....
No, it causes ambiguities. Does 1:20 mean an hour and 20 minutes or a minute
and 20 seconds? It is better to just require both ':'. 0:01:20 is a minute
and 20 seconds, 1:20:00 is an hour and 20 minutes.
It seems we have the following alternatives:
(1) Keep things as they are, and live with YAML core types providing a
partial solution to the date/time problem;
(2) Add timeperiod in the hope it solves the problem.
(3) Drop date and time altogether and live with YAML core types providing no
solution to this issue.
I think (1) isn't really an option. Having half a solution is worse than
While (2) _seems_ to solve the problem, there are probably subtleties we are
missing. It is at best an 80% solution.
Brian likes (3) and I can see his point. After all, it allows you to write
your dates unquoted. So they are interpreted as strings, leaving it to the
application to bother about their semantics. In this respect they are no
different from E-mail addresses, URLs, IP addresses, paths, regular
expressions, and a zillion other "types". It isn't clear why dates deserve a
special status here.
So, I'm tending towards (3) as well. We still have to wait for Clark to come
back on-line before we finalize any decision, however.
It is interesting that the first changes that come to mind for the last-call
draft are to *remove* things from it :-)