time packages

[Patrick May]

I've been spending some quality time with encode-universal-time,
decode-universal-time, and the joy of time zones. I need to store time
ranges for multiple time zones in a database, update and retrieve them,
and perform some comparisons relative to the current time and future
times. Postgres handles the storage fine, but juggling time zones in
Lisp is becoming more trouble than it's worth.

I'm just about to rewrite this module to always use UTC and only
change the values for display, but before I do I was wondering if anyone
had a recommendation for a good time package.

Thanks,

Patrick

[Madhu]

* Patrick May <m2sj1nl...@gulch.gateway.2wire.net> :
Wrote on Wed, 15 May 2013 22:26:12 -0400:

Since you are not dealing with accuracy beyond seconds or dates before
1900, I believe ENCODE-UNIVERSAL-TIME and DECODE-UNIVERSAL-TIME are
enough to define your own abstractions for your specific application,
for the stated tasks. You will require 1-2 functions at most.

Exactly what is it that you think is missing that needs a library/API
that someone else has thought out? interfacing with zoneinfo databases?

--- Madhu

[Pascal J. Bourguignon]

Patrick May <pat...@softwarematters.org> writes:

> I've been spending some quality time with encode-universal-time,
> decode-universal-time, and the joy of time zones. I need to store time
> ranges for multiple time zones in a database, update and retrieve them,
> and perform some comparisons relative to the current time and future
> times. Postgres handles the storage fine, but juggling time zones in
> Lisp is becoming more trouble than it's worth.

Universal times in lisps are seconds since 1900-01-01 00:00:00 UTC.
I don't see what trouble you may have dealing with such a simple
representation.

> I'm just about to rewrite this module to always use UTC and only
> change the values for display, but before I do I was wondering if anyone
> had a recommendation for a good time package.

cliki says local-time.

http://cliki.net/site/search?query=time


--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
You can take the lisper out of the lisp job, but you can't take the lisp out
of the lisper (; -- antifuchs

[Dimitri Fontaine]

Patrick May <pat...@softwarematters.org> writes:
> I've been spending some quality time with encode-universal-time,
> decode-universal-time, and the joy of time zones. I need to store time
> ranges for multiple time zones in a database, update and retrieve them,
> and perform some comparisons relative to the current time and future
> times. Postgres handles the storage fine, but juggling time zones in
> Lisp is becoming more trouble than it's worth.

PostgreSQL handles way more than just the storage, I would advice
pushing your time computations down to it. In particular in 9.2 you
might be interested by the new RANGE facility and the tstzrange data
type and associated operators and functions:

http://www.postgresql.org/docs/current/static/rangetypes.html
http://www.postgresql.org/docs/current/static/functions-range.html
http://www.postgresql.org/docs/current/static/functions-datetime.html

> I'm just about to rewrite this module to always use UTC and only
> change the values for display, but before I do I was wondering if anyone
> had a recommendation for a good time package.

I'm currently using local-time, but didn't have to fiddle with TZ
handling with it yet. It seems to be supposed to know how to deal with
them though.

You can easily 'set timezone to utc' in your PostgreSQL session if you
really want to be doing that.

If you want to use the same TZ definitions (tzinfo) in PostgreSQL and
your Lisp system, you might want to check that PostgreSQL is using the
system's TZ information rather than its own (use pg_config --configure
and watch for the --with-system-tzdata option).

Regards,
--
dim

[Patrick May]

"Pascal J. Bourguignon" <p...@informatimago.com> writes:
> Patrick May <pat...@softwarematters.org> writes:
>
>> I've been spending some quality time with encode-universal-time,
>> decode-universal-time, and the joy of time zones. I need to store time
>> ranges for multiple time zones in a database, update and retrieve them,
>> and perform some comparisons relative to the current time and future
>> times. Postgres handles the storage fine, but juggling time zones in
>> Lisp is becoming more trouble than it's worth.
>
> Universal times in lisps are seconds since 1900-01-01 00:00:00 UTC.
> I don't see what trouble you may have dealing with such a simple
> representation.

I have business hours and holidays specified by multiple customers
in different time zones. I need to determine if the customer is open at
a particular time (either the current time or a future time). My
initial thought was to use the Postgres TIME(0) WITH ZONE format and
encode-universal-time with time-zone specified as appropriate for the
customer.

In practice, keeping the timezones between Lisp and Postgres
aligned is a minor annoyance and the fact that decode-universal-time
returns the current daylight-p and zone rather than the one I specified
with encode-universal-time (in ccl) violates the principle of least
surprise for me. I thought that someone else might already have
addressed these issues.

>> I'm just about to rewrite this module to always use UTC and only
>> change the values for display, but before I do I was wondering if anyone
>> had a recommendation for a good time package.
>
>
> cliki says local-time.
>
> http://cliki.net/site/search?query=time

Thanks, that's the kind of thing I was looking for.

Patrick

[Patrick May]

Mostly. I'm looking at local-time, as recommended by a couple of
other people.

Thanks,

Patrick

[Patrick May]

Dimitri Fontaine <d...@tapoueh.org> writes:
> I'm currently using local-time, but didn't have to fiddle with TZ
> handling with it yet. It seems to be supposed to know how to deal with
> them though.

That's two votes for local-time, I'll give it a try.

Thanks,

Patrick

[Dimitri Fontaine]

Patrick May <pat...@softwarematters.org> writes:
> In practice, keeping the timezones between Lisp and Postgres
> aligned is a minor annoyance and the fact that decode-universal-time
> returns the current daylight-p and zone rather than the one I specified
> with encode-universal-time (in ccl) violates the principle of least
> surprise for me. I thought that someone else might already have
> addressed these issues.

I can't guess if that's related, but PostgreSQL will not store the
original TimeZone of any timestamptz value you give it, its internals
only deal with UTC times.

So if you want to know which TimeZone the time has been entered first,
you need to keep that yourself.

--
dim

[Elias Mårtenson]

On Friday, 17 May 2013 00:35:47 UTC+8, Dimitri Fontaine wrote:

> I can't guess if that's related, but PostgreSQL will not store the
> original TimeZone of any timestamptz value you give it, its internals
> only deal with UTC times.
>
> So if you want to know which TimeZone the time has been entered first,
> you need to keep that yourself.

Normally you wouldn't need to, though. A meeting happens at a given point in time. Timezones doesn't come into play at all until it's time to display it.

[Dan Lentz]

There is a package named "periods" available on github which seems quite comprehensive and very nice. I haven't worked with it personally but you might want to take a look and see if it could be useful for your specific needs. The github URL is: https://github.com/jwiegley/periods

Hope this helps
Dan