[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: parse_time()
From: |
Bruno Haible |
Subject: |
Re: parse_time() |
Date: |
Sun, 2 Nov 2008 22:11:39 +0100 |
User-agent: |
KMail/1.5.4 |
> 3? I only see one, though with lots of optional fields.
I meant the three: PnYnMnDTnHnMnS, PnW, and P<date>T<time>.
> That format also doesn't allow for visual space.
Yes, it's more meant for durations that are exchanged between software,
not entered by humans.
> The little question remaining though is "how many seconds in a year"
> and, more importantly, "how many seconds in a month"? In other words,
> if some one in February were expecting P1M to represent a 28 day duration
> and a 31 day duration had it been March, um, well,
Very good point. Maybe this means the functionality is better broken down
into a parsing stage and a conversion stage which ultimately produces seconds.
The state between these two would be a struct { year, months, weeks, days, ...
}.
Hmm?
> Dealing with "leap seconds" would get extremely over the top.
Yes. Leap seconds are important if you are at NASA or doing astronomy, but not
otherwise.
Bruno
- parse_time(), Bruce Korb, 2008/11/01
- Re: parse_time(), Bruno Haible, 2008/11/02
- Re: parse_time(), Bruce Korb, 2008/11/02
- Re: parse_time(),
Bruno Haible <=
- Re: parse_duration(), Bruce Korb, 2008/11/02
- Re: parse_duration(), Bruno Haible, 2008/11/03
- Re: parse_duration(), Bruce Korb, 2008/11/04
- Re: parse_duration(), Bruno Haible, 2008/11/05
- Re: parse_duration(), Bruce Korb, 2008/11/05
- Re: parse_duration(), Bruce Korb, 2008/11/16
- Re: parse_duration(), Bruno Haible, 2008/11/17
Re: parse_time(), Bruce Korb, 2008/11/02