Hi, Quoting briand@aracnet.com:

...

which is a variation of the question, why can't I compare localtimes ? or am I missing something in Time (yet again).

Am Mittwoch, den 31.03.2010, 01:32 -0400 schrieb wagnerdm@seas.upenn.edu:

Two values of LocalTime may well be computed with respect to different timezones, which makes the operation you ask for dangerous. First convert to UTCTime (with localTimeToUTC), then compare.

but this leads to the question: Why can I not compare or diff ZonedTime? Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org

On Wed, 2010-03-31 at 19:29 -0700, briand@aracnet.com wrote:

On Wed, 31 Mar 2010 01:32:56 -0400 wagnerdm@seas.upenn.edu wrote:

...

Two values of LocalTime may well be computed with respect to different timezones, which makes the operation you ask for dangerous. First convert to UTCTime (with localTimeToUTC), then compare.

that makes sense. unfortunately getting the current timezone to convert to UTC results in the dreaded IO contamination problem...

Brian

Hmm. Where do you get the local times from in the first place? Regards PS. As the timezone can change in runtime (like change from summer time to standard or simply crossing the 'border' with laptop) I don't think that there is escape from IO.

briand@aracnet.com

Maciej Piechotka wrote:

...

On Wed, 2010-03-31 at 19:29 -0700, briand@aracnet.com wrote:

...

wagnerdm@seas.upenn.edu wrote:

...

Two values of LocalTime may well be computed with respect to different timezones, which makes the operation you ask for dangerous. First convert to UTCTime (with localTimeToUTC), then compare.

that makes sense. unfortunately getting the current timezone to convert to UTC results in the dreaded IO contamination problem...

Brian

Hmm. Where do you get the local times from in the first place?

read it from a file of course :-)

I think I've got it figured out. it's not too ugly.

One interesting "hole" in the system is that buildTime can return a LocalTime _or_ a UTCTime. That means the same string used to generate a time can give you two different times.

It seems as thought it should be restricted to always returning a UTCTime. If it's going to return a local time it should require an extra argument of a timezone, shouldn't it ?

LocalTime is just day+time, sans TimeZone (so it could be in any timezone). ZonedTime is LocalTime with TimeZone. The functions to convert to UTCTime give a clue: zonedTimeToUTC :: ZonedTime -> UTCTime localTimeToUTC :: TimeZone -> LocalTime -> UTCTime i.e. ZonedTime can convert with no additional information (so in a sense is equivalent), but for LocalTime you need to say which TimeZone to use. If all you have in your file is day_time, you're going to have to get a TimeZone from somewhere, in order to convert to UTCTime. If all you're doing is diffing the LocalTimes, and they are all in the same TimeZone, then any TimeZone will do, I guess. Perhaps add what you learn to one or more of these pages: http://haskell.org/haskellwiki/Cookbook/Dates_And_Time http://haskell.org/haskellwiki/Libraries_and_tools/Time_library or create a new wiki page with better docs for Data.Time? (aside: do we have a policy for naming pages that augment library documentation? what about under here? http://haskell.org/haskellwiki/Library e.g. http://haskell.org/haskellwiki/Library/Time ) Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************