Yeah... I've debated several times whether to shell out the 138 Swiss
francs for a copy.
There is a bit of support for the week-based calendar in Gregor
(->iso-week, ->iso-wyear, and ->iso-wday are defined on
date-provider), but the I've never actually used the week-based
calendar, which makes it
I've used a library like this before
[https://github.com/jeremyw/stamp], and realized that there were two
things I didn't like about it: (1) potential ambiguity in the
(user-)chosen exemplar date/time and (2) my tendency to mistake the
exemplar date for an actual piece of data in the program. Go's
BTW, the ISO 8601 standard (I don't mean the trivial "ISO 8601 date/time
format" everybody knows) has done a lot on concepts you might want to
look at. Beware that ISO 8601 is big, and there is some baffling stuff
included, but you can't always tell what is important.
One thing I can tell you
On Thu, Mar 26, 2015 at 10:51 AM, Vincent St-Amour wrote:
> This is really cool!
>
> Do you have plans for operations on durations?
>
> Vincent
More vague thoughts than plans.
So-- there's a useful distinction (that comes out of Joda-Time)
between a duration, which is directly convertible to som
Gregor shares the near-universal disdain for UTC exhibited by operating systems
and date/time libraries alike.
Seriously, though: Gregor doesn't keep UTC time, so there are no leap seconds.
I mentioned in the docs that if there's a real demand for UTC, I'll implement
it.
- Jon
> On Mar 26,
On Thu, Mar 26, 2015 at 2:57 PM, Vincent St-Amour wrote:
> At Thu, 26 Mar 2015 14:30:28 -0400, Jon Zeppieri wrote:
>>
>> On Thu, Mar 26, 2015 at 10:51 AM, Vincent St-Amour
>> wrote:
>> - Is a "duration" data structure, distinct from some number of
>> nanoseconds, useful? In Joda it seems largely
Yeah, these are really good ideas.
Thanks!
- Jon
On Mar 26, 2015, at 5:55 PM, Greg Hendershott wrote:
>>> - Assuming that "periods" are useful, what operations on them do we
>>> want? Arithmetic, probably; maybe the `period->nanoseconds` function I
>>> just mentioned; maybe convenience function
>> - Assuming that "periods" are useful, what operations on them do we
>> want? Arithmetic, probably; maybe the `period->nanoseconds` function I
>> just mentioned; maybe convenience functions based on the current time
>> (e.g., `ago`, `from-now`). Anything else?
1. For scheduling apps people often
2015-03-26 22:30 GMT+01:00 Jon Zeppieri :
> On Thu, Mar 26, 2015 at 5:27 PM, Robby Findler
>> Would 3 weeks and 40 hours always be a precise number of
>> seconds?
>>
>> Robby
What about leap seconds?
/Jens Axel
--
You received this message because you are subscribed to the Google Groups
"Rac
On Thu, Mar 26, 2015 at 4:31 PM, Jon Zeppieri wrote:
> On Thu, Mar 26, 2015 at 5:30 PM, Jon Zeppieri wrote:
>>
>> 3 weeks and 40 hours will always have a fixed number of seconds...
>
> And this is because Gregor isn't faithful to UTC, of course.
> Otherwise, this wouldn't be true.
Right; I notic
On Thu, Mar 26, 2015 at 5:30 PM, Jon Zeppieri wrote:
>
> 3 weeks and 40 hours will always have a fixed number of seconds...
And this is because Gregor isn't faithful to UTC, of course.
Otherwise, this wouldn't be true.
--
You received this message because you are subscribed to the Google Groups
On Thu, Mar 26, 2015 at 5:27 PM, Robby Findler
wrote:
> On Thu, Mar 26, 2015 at 4:13 PM, Jon Zeppieri wrote:
>> You
>> can carry around a bucket that says "5 years, 3 weeks, and 40 hours,"
>> but the precise number of seconds inside the bucket is indeterminate
>> until you pour it over a date-pro
On Thu, Mar 26, 2015 at 4:13 PM, Jon Zeppieri wrote:
> You
> can carry around a bucket that says "5 years, 3 weeks, and 40 hours,"
> but the precise number of seconds inside the bucket is indeterminate
> until you pour it over a date-provider. (No, not a great metaphor.)
I have a feeling I'm goin
On Thu, Mar 26, 2015 at 4:57 PM, Vincent St-Amour wrote:
> At Thu, 26 Mar 2015 14:30:28 -0400,
> Jon Zeppieri wrote:
>>
[ snip]
> Since, IIUC, periods need to be "anchored" to a specific point in time,
> that would make them a bit more heavyweight to create. I could see
> durations being nice fo
At Thu, 26 Mar 2015 14:30:28 -0400,
Jon Zeppieri wrote:
>
> On Thu, Mar 26, 2015 at 10:51 AM, Vincent St-Amour
> wrote:
> > This is really cool!
> >
> > Do you have plans for operations on durations?
> >
> > Vincent
>
> More vague thoughts than plans.
>
> So-- there's a useful distinction (tha
On Thu, Mar 26, 2015 at 3:56 PM, John Clements
wrote:
>
> On Mar 25, 2015, at 6:55 PM, Jon Zeppieri wrote:
>
>> I recently uploaded Gregor, a date and time library, to the package server.
>
> Can I use this instead of SRFI 19? That would be wonderful.
>
> John Clements
Please do, and let me know
On Mar 25, 2015, at 6:55 PM, Jon Zeppieri wrote:
> I recently uploaded Gregor, a date and time library, to the package server.
Can I use this instead of SRFI 19? That would be wonderful.
John Clements
>
> Features:
>
> - representations for and generic operations on:
> - dates
> - times
This is really cool!
Do you have plans for operations on durations?
Vincent
At Wed, 25 Mar 2015 21:55:31 -0400,
Jon Zeppieri wrote:
>
> I recently uploaded Gregor, a date and time library, to the package server.
>
> Features:
>
> - representations for and generic operations on:
> - dates
This is so awesome.
Jay
On Wed, Mar 25, 2015 at 9:55 PM, Jon Zeppieri wrote:
> I recently uploaded Gregor, a date and time library, to the package server.
>
> Features:
>
> - representations for and generic operations on:
> - dates
> - times (as in, time-of-day)
> - datetimes (combined dat
I recently uploaded Gregor, a date and time library, to the package server.
Features:
- representations for and generic operations on:
- dates
- times (as in, time-of-day)
- datetimes (combined date and time)
- moments (combined datetime and IANA/Olson timezone)
- date arithmetic
- locali
20 matches
Mail list logo
