Re: [Haskell-cafe] Data.Time
On Mon, 2011-07-04 at 10:38 +0300, Yitzchak Gale wrote: > > Leap second data is there too, so it should be possible to create a > > Data.Time.Clock.TAI.LeapSecondTable from it. > > No, unfortunately. There is a place in the data structure > for leap second information, but no live Olson > file has every populated it AFAIK. Have a look at the "right/UTC" timezone, I think leap-second data is represented there. But "zdump right/UTC" does not give you the TAI time. Quite the opposite, it gives you the UTC time if your clock is set to TAI. -- Ashley Yakeley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
I wrote: >> Not exactly. A "TimeZone" in Data.Time doesn't really >> represent a time zone - it represents a specific clock setting >> in a time zone. Ashley Yakeley wrote: > I still regret this! I should have called it TimeOffset or somesuch. Oh, it's not your fault. Every other time library in the world calls that a "time zone". You've gotten so many other more substantial things right that so many others got wrong. This name is nothing to worry about. >> To get a TimeZoneSeries, representing a time zone with >> all of its known clock changes throughout history and some >> years into the future, use the timezone-olson package[2] to >> read an Olson time zone file. On Linux and Mac OS X >> systems, Olson time zone files are available in the directory >> /usr/share/zoneinfo. > Leap second data is there too, so it should be possible to create a > Data.Time.Clock.TAI.LeapSecondTable from it. No, unfortunately. There is a place in the data structure for leap second information, but no live Olson file has every populated it AFAIK. That's not so important though. There have been very few leap seconds in history, and they occur rarely. Their release cycle has been slower than the usual release cycle of software packages. So this is something that could easily be done manually. > Also, it might be worth creating an OS-specific package > that dealt with the filepaths for you, so for instance you > could read in a TimeZoneSeries given > a time zone name such as America/Los_Angeles. That would be nice. Perhaps a higher priority would be to add support for Windows, where the Olson data is in the registry rather than in the file system. Right now, people on Windows are still dependent on asking a favor from their friends to lend them copies of the latest Olson files. Another important enhancement would be support for POSIX rules. Olson files still supply explicit clock changes for about two decades into the future. But I believe that will gradually end now that the new Olson file format supports POSIX rules for clock changes beyond the last one explicitly specified. (And besides being supported, recently released Olson files actually do contain the POSIX rules. So does the Windows registry.) Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
On 2011-07-02 14:03, Yitzchak Gale wrote: Not exactly. A "TimeZone" in Data.Time doesn't really represent a time zone - it represents a specific clock setting in a time zone. I still regret this! I should have called it TimeOffset or somesuch. To get a TimeZoneSeries, representing a time zone with all of its known clock changes throughout history and some years into the future, use the timezone-olson package[2] to read an Olson time zone file. On Linux and Mac OS X systems, Olson time zone files are available in the directory /usr/share/zoneinfo. Leap second data is there too, so it should be possible to create a Data.Time.Clock.TAI.LeapSecondTable from it. Also, it might be worth creating an OS-specific package that dealt with the filepaths for you, so for instance you could read in a TimeZoneSeries given a time zone name such as America/Los_Angeles. -- Ashley Yakeley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
On 2 Jul 2011, at 22:13, Yitzchak Gale wrote: > [1]http://hackage.haskell.org/package/timezone-series > [2]http://hackage.haskell.org/package/timezone-olson I'd just like to add that these timezone packages are fantastic. They are extremely useful if you need accurate conversion between wall-clock times in different locations of the world, at arbitrary dates in the past or future, taking account of the differing moments at which daylight savings times take effect and so on. [At least one financial institution is now using them to avoid losing money that might otherwise happen due to confusion over the exact time of expiry of contracts.] Thanks Yitz. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
Oops, forgot the references: > ZoneSeriesTime in the timezone-series package[1]... > To get a TimeZoneSeries, representing a time zone with > all of its known clock changes throughout history and some > years into the future, use the timezone-olson package[2] [1]http://hackage.haskell.org/package/timezone-series [2]http://hackage.haskell.org/package/timezone-olson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
Joe Healy wrote: >> One of the points I found "non obvious" were the fact that local time is >> just that. There is no knowledge of the actual timezone in the data >> type. If you wish to store that, it needs to be stored alongside. Erik Hesselink wrote: > Isn't that what ZonedTime [1] is for? Not exactly. A "TimeZone" in Data.Time doesn't really represent a time zone - it represents a specific clock setting in a time zone. Clock settings periodically change in a time zone - e.g., to or from summer time, or due to government decree. A ZonedTime is a LocalTime together with a specific clock setting in a time zone. There is no guarantee that the clock setting was actually in effect at the given LocalTime. So a ZonedTime is only useful if you have checked separately that it is consistent, or if you don't care. ZoneSeriesTime in the timezone-series package[1] more accurately represents a moment in time in a given time zone. There the moment is represented as a UTCTime, not a LocalTime. The reason is that a LocalTime in a time zone does not necessarily represent a unique moment. When the LocalTime happens to be near a clock change, it can represent zero moments or more than one moment. To get the LocalTime from a ZoneSeriesTime, use the function zoneSeriesTimeToLocalTime. To get a TimeZoneSeries, representing a time zone with all of its known clock changes throughout history and some years into the future, use the timezone-olson package[2] to read an Olson time zone file. On Linux and Mac OS X systems, Olson time zone files are available in the directory /usr/share/zoneinfo. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
On Sat, 2011-07-02 at 12:43 +0200, Erik Hesselink wrote: > On Saturday, July 2, 2011, Joe Healy wrote: > > One of the points I found "non obvious" were the fact that local time is > > just that. There is no knowledge of the actual timezone in the data > > type. If you wish to store that, it needs to be stored alongside. > > Isn't that what ZonedTime [1] is for? > > [1] > http://hackage.haskell.org/packages/archive/time/1.1.4/doc/html/Data-Time-LocalTime.html Ahahh - learning more all the time. Is there a good place to put a set of beginner examples of this sort of stuff? Exactly like I missed this type. Joe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
On Saturday, July 2, 2011, Joe Healy wrote: > One of the points I found "non obvious" were the fact that local time is > just that. There is no knowledge of the actual timezone in the data > type. If you wish to store that, it needs to be stored alongside. Isn't that what ZonedTime [1] is for? [1] http://hackage.haskell.org/packages/archive/time/1.1.4/doc/html/Data-Time-LocalTime.html Erik > I've attached my test program in the hope that it will be useful for > someone (or if it is bad, get some help). Is there somewhere/way to > contribute some examples or documentation? I feel the time home page > (http://semantic.org/TimeLib/) makes the library feel more experimental > than it really is. > > Cheers, > > Joe > > > On Mon, 2011-06-27 at 07:37 -0700, bri...@aracnet.com wrote: >> On Mon, 27 Jun 2011 11:15:28 +0300 >> Yitzchak Gale wrote: >> >> > >> > The biggest shortcoming, in my opinion, is that the documentation >> > assumes that the reader is very familiar with the Haskell type >> > system, and with viewing type signatures and instance lists as an >> > integral and central part of the documentation. >> > >> > In particular, Haskell's standard numeric type classes and the >> > conversion functions between them play a central role in the API >> > of Data.Time. But you wouldn't realize that unless you have read >> > the type signatures and instance lists in the Haddocks very >> > carefully, and have thought about it for a while. >> >> This is exactly right. >> >> > >> > Another problem, as Malcolm pointed out, is that because of the >> > sheer size of the library, a quick-start guide for the common >> > cases would be extremely helpful for newcomers. >> >> That would be very, very helpful. I had a few working examples things were >> much better. Finding a starting place, any starting place, proved to be >> quite elusive. Also the fact that asking for the current time traps you in >> IO hell, doesn't help, although it's clear that it should be that way. >> >> Brian >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
As someone who has failed at using Data.Time in the past (but has now had some success), I used the attached code as an example to try out the various things I commonly need to do. One of the points I found "non obvious" were the fact that local time is just that. There is no knowledge of the actual timezone in the data type. If you wish to store that, it needs to be stored alongside. I've attached my test program in the hope that it will be useful for someone (or if it is bad, get some help). Is there somewhere/way to contribute some examples or documentation? I feel the time home page (http://semantic.org/TimeLib/) makes the library feel more experimental than it really is. Cheers, Joe On Mon, 2011-06-27 at 07:37 -0700, bri...@aracnet.com wrote: > On Mon, 27 Jun 2011 11:15:28 +0300 > Yitzchak Gale wrote: > > > > > The biggest shortcoming, in my opinion, is that the documentation > > assumes that the reader is very familiar with the Haskell type > > system, and with viewing type signatures and instance lists as an > > integral and central part of the documentation. > > > > In particular, Haskell's standard numeric type classes and the > > conversion functions between them play a central role in the API > > of Data.Time. But you wouldn't realize that unless you have read > > the type signatures and instance lists in the Haddocks very > > carefully, and have thought about it for a while. > > This is exactly right. > > > > > Another problem, as Malcolm pointed out, is that because of the > > sheer size of the library, a quick-start guide for the common > > cases would be extremely helpful for newcomers. > > That would be very, very helpful. I had a few working examples things were > much better. Finding a starting place, any starting place, proved to be > quite elusive. Also the fact that asking for the current time traps you in > IO hell, doesn't help, although it's clear that it should be that way. > > Brian > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe module Main where import Data.Time main = do tz <- getCurrentTimeZone putStrLn (show tz) putStrLn (unlines (example tz)) example tz = [show (read "2012-10-25" :: Day), --parsing show (d0), show (d1), show (addDays 7 d0), -- addition of days to Day show (read "2012-10-23 14:23:12" :: UTCTime), show (read "2012-10-23 14:23:12" :: LocalTime), show (diffDays d0 d1), show (diffDays (addDays 7 d0) d0), show (utctDay t0), show (utctDayTime t0), show (addUTCTime 42 t0), -- adding of 42 seconds show (addUTCTime 3600 t0), -- adding of 1 hour show (diffUTCTime t0 t0_1), show (UTCTime (addDays 7 (utctDay t0)) (utctDayTime t0)), -- putting it all back together show (utcToLocalTime tz t0), show (localTimeToUTC tz t1) ] where d0 = read "2012-10-25" -- derived as Day d1 = fromGregorian 2013 10 25 t0 = read "2012-10-23 14:23:12" -- derived as UTCTime t0_1 = read "2012-10-23 15:23:12" -- derived as UTCTime t1 = read "2012-10-23 14:23:12" -- derived as LocalTime ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
On Mon, 27 Jun 2011 11:15:28 +0300 Yitzchak Gale wrote: > > The biggest shortcoming, in my opinion, is that the documentation > assumes that the reader is very familiar with the Haskell type > system, and with viewing type signatures and instance lists as an > integral and central part of the documentation. > > In particular, Haskell's standard numeric type classes and the > conversion functions between them play a central role in the API > of Data.Time. But you wouldn't realize that unless you have read > the type signatures and instance lists in the Haddocks very > carefully, and have thought about it for a while. This is exactly right. > > Another problem, as Malcolm pointed out, is that because of the > sheer size of the library, a quick-start guide for the common > cases would be extremely helpful for newcomers. That would be very, very helpful. I had a few working examples things were much better. Finding a starting place, any starting place, proved to be quite elusive. Also the fact that asking for the current time traps you in IO hell, doesn't help, although it's clear that it should be that way. Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
On 2011-June-27 Monday 10:15:28 Yitzchak Gale wrote: > The biggest shortcoming, in my opinion, is that the documentation > assumes that the reader is very familiar with the Haskell type > system, and with viewing type signatures and instance lists as an > integral and central part of the documentation. > > In particular, Haskell's standard numeric type classes and the > conversion functions between them play a central role in the API > of Data.Time. Making use of Haddock's recently added(?) support for comments on instance declaration would help a lot here, I think (even if it was just to draw attention to the Num/Integral/Real/Fractional instances). > Before you undertake writing a whole new time library, why not > try writing some improved documentation for Data.Time first? I got the impression that Tony's issue with Data.Time was the lack of some feature, not usability. Seems like the details that were omitted for the sake of constructiveness are quite relevant :) Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
Tony Morris wrote: > I recently set out to write a library that required a decent time > library. Having only had a flirt with Data.Time previously, I assumed > it would be robust like many other haskell libraries. I don't know > about consensus, but I have been massively let down. I won't go in to > the details... Data.Time is in some ways like Haskell itself. Though at first glance it seems a little daunting, in reality its semantic correctness makes it easier to use, not harder, than any of its alternatives in any language that I know (and I am proficient in quite a few). Once you have caught on, it is difficult to settle for anything less. The biggest shortcoming, in my opinion, is that the documentation assumes that the reader is very familiar with the Haskell type system, and with viewing type signatures and instance lists as an integral and central part of the documentation. In particular, Haskell's standard numeric type classes and the conversion functions between them play a central role in the API of Data.Time. But you wouldn't realize that unless you have read the type signatures and instance lists in the Haddocks very carefully, and have thought about it for a while. Another problem, as Malcolm pointed out, is that because of the sheer size of the library, a quick-start guide for the common cases would be extremely helpful for newcomers. What other issues have you noticed? > is there a reasonable alternative to Data.Time > If I am right, and there is no alternative, I see no option but to > take an excursion into writing my own. No. There are several alternatives, but I have never seen anything that has come close to Data.Time. Before you undertake writing a whole new time library, why not try writing some improved documentation for Data.Time first? I think that would give the most immediate benefit to the community, and I'm sure it would improve the quality of whatever library of your own you end up writing. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
On 26 Jun 2011, at 01:53, Tony Morris wrote: > Having only had a flirt with Data.Time previously, I assumed > it would be robust like many other haskell libraries. If, by lack of robustness, you mean that you get runtime errors, then consider them bugs, and file them with the author/maintainer accordingly. If you mean something else, then being more specific might be useful. I know that the first time I looked seriously at Data.Time it seemed rather byzantine and labyrinthine. So many types! So few direct conversions between them! But when you think more closely about the domain, you realise that notions of time are not simple at all, and have varied widely over history, and the complexity of Data.Time only reflects the complexity of the domain. The old-time package is still available, and has a much simplified approach to time (which is evidently wrong in many places), but may better suit the needs of applications that only care to be approximate. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
I've tended to use the attached module. It is basic, but has covered my needs. It probably has many issues (bugs, inefficiencies, naming conventions, etc) but has been sufficient so far. Developed by myself a few years ago, under no particular licence - happy for reuse or for someone to take it and package it up under cabal if it is useful or maybe even better for someone to suggest a simple alternative. cheers, Joe > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I recently set out to write a library that required a decent time > library. Having only had a flirt with Data.Time previously, I assumed > it would be robust like many other haskell libraries. I don't know > about consensus, but I have been massively let down. I won't go in to > the details, since this is not the point -- I don't wish to complain > - -- I wish to get on with it. > > So, assuming the consensus is in agreement, is there a reasonable > alternative to Data.Time (I looked on hackage and nothing seemed to > have come close)? Am I wrong in assuming Data.Time is pretty useless? > > If I am right, and there is no alternative, I see no option but to > take an excursion into writing my own. Ultimately, I am just trying to > avoid this. Tips welcome. > > - -- > Tony Morris > http://tmorris.net/ > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk4Ggx4ACgkQmnpgrYe6r61BRQCfbn+1jqNSjR+lxM+4h3gpvAMM > VskAoKxqDCETyVAaOdoYDmFJGz1fOGd/ > =IC7O > -END PGP SIGNATURE- > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > --module Dates (datetime, sixNum, hours, minutes, seconds, -- yearPart, monthPart, dayPart, -- hourPart, minutePart, secondPart, dateFromString, -- dateSub, dateAdd, Date, TimeSpan, fromNum, toNum, hms) where module Dates where data Date = Date Int Int deriving (Eq, Ord) data TimeSpan = TimeSpan Int deriving (Show, Eq, Ord) instance Show Date where show = toString instance Enum Date where pred (Date d s) = Date (d-1) s succ (Date d s) = Date (d+1) s toEnum d = Date d 0 fromEnum (Date d _) = d enumFrom d = (d:(enumFrom (succ d))) enumFromThen a b = (a:(enumFromThen b (dateAdd b (dateSub b a enumFromThenTo a b c = takeWhile (<= c) (enumFromThen a b) isLeapYear :: Int -> Bool isLeapYear x | x `mod` 400 == 0 = True | x `mod` 100 == 0 = False | x `mod` 4 == 0 = True | otherwise= False daysInMonth :: Int -> Int -> Int daysInMonth _ 1 = 31 daysInMonth y 2 | isLeapYear y = 29 | otherwise= 28 daysInMonth _ 3 = 31 daysInMonth _ 4 = 30 daysInMonth _ 5 = 31 daysInMonth _ 6 = 30 daysInMonth _ 7 = 31 daysInMonth _ 8 = 31 daysInMonth _ 9 = 30 daysInMonth _ 10 = 31 daysInMonth _ 11 = 30 daysInMonth _ 12 = 31 daysInMonth _ x = 0 daysInYear x | isLeapYear x = 366 | otherwise= 365 normalize :: Date -> Date normalize (Date days seconds) = (Date (days + sdays) sseconds) where sdays = seconds `div` 86400 sseconds = seconds `mod` 86400 baseYear = 2000 datetime :: Int -> Int -> Int -> Int -> Int -> Int -> Date datetime y m d h minute s = (Date days seconds) where days = yearDays + monthDays + d - 1 yearDays = sum [daysInYear x | x <- [baseYear..(y-1)]] monthDays = sum [(daysInMonth y x) | x <- [1..(m-1)]] seconds = h * 3600 + minute * 60 + s toString d = concat [(p 4 year), "-", (p 2 month), "-", (p 2 day), " ", (p 2 hour), ":", (p 2 minute), ":", (p 2 second)] where (year, month, day, hour, minute, second) = sixNum d p x v = pad (show v) x dateFromString s = datetime (read year) (read month) (read day) (read hour) (read minute) (read second) where (dpart:tpart:xs) = split s ' ' (year:month:day:[]) = split dpart '-' (hour:minute:second:[]) = split tpart ':' toNum d = x where (TimeSpan x) = dateSub d (datetime 2000 1 1 0 0 0) fromNum d = dateAdd (datetime 2000 1 1 0 0 0) (TimeSpan d) sixNum d = (year, month, mdaysRemaining, hour, minute, second) where (Date days seconds) = normalize d (year, ydaysBefore) = yearOf days ydaysRemaining = days - ydaysBefore (month, mdaysBefore) = monthOf year ydaysRemaining mdaysRemaining = ydaysRemaining - mdaysBefore + 1 hour = seconds `div` 3600 minute = (seconds `mod` 3600) `div` 60 second = seconds - (hour * 3600) - (minute * 60) yearPart d = x where (x, _, _, _, _, _) = sixNum d monthPart d = x where (_, x, _, _, _, _) = sixNum d dayPart d = x where (_, _, x, _, _, _) = sixNum d hourPart d = x where (_, _, _, x, _, _) = sixNum d minutePar
[Haskell-cafe] Data.Time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I recently set out to write a library that required a decent time library. Having only had a flirt with Data.Time previously, I assumed it would be robust like many other haskell libraries. I don't know about consensus, but I have been massively let down. I won't go in to the details, since this is not the point -- I don't wish to complain - -- I wish to get on with it. So, assuming the consensus is in agreement, is there a reasonable alternative to Data.Time (I looked on hackage and nothing seemed to have come close)? Am I wrong in assuming Data.Time is pretty useless? If I am right, and there is no alternative, I see no option but to take an excursion into writing my own. Ultimately, I am just trying to avoid this. Tips welcome. - -- Tony Morris http://tmorris.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4Ggx4ACgkQmnpgrYe6r61BRQCfbn+1jqNSjR+lxM+4h3gpvAMM VskAoKxqDCETyVAaOdoYDmFJGz1fOGd/ =IC7O -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time is so weak ?!
toWeekDate meets my need, thank you! Colin Adams-3 wrote: > > How about: > > import Data.Time.Calendar > import Data.Time.Calendar.WeekDate > > main = do > let (y, w, d) = toWeekDate $ addDays 150 (fromGregorian 2009 8 31) > putStrLn $ show d > > > 2009/8/31 zaxis : >> >> addDays 150 (fromGregorian 2009 8 31) will work. However, how can i get >> its >> weekday from the result ? >> >> thanks! >> >> >> zaxis wrote: >>> >>> today = fromGregorian 2009 8 31 >>> >>> then how to calculate the day passing 150 days ? >>> >>> today + 150 doesnot work ! >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Data.Time-is-so-weak--%21-tp25218462p25218554.html >> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > Colin Adams > Preston, > Lancashire, > ENGLAND > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- View this message in context: http://www.nabble.com/Data.Time-is-so-weak--%21-tp25218462p25219065.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time is so weak ?!
How about: import Data.Time.Calendar import Data.Time.Calendar.WeekDate main = do let (y, w, d) = toWeekDate $ addDays 150 (fromGregorian 2009 8 31) putStrLn $ show d 2009/8/31 zaxis : > > addDays 150 (fromGregorian 2009 8 31) will work. However, how can i get its > weekday from the result ? > > thanks! > > > zaxis wrote: >> >> today = fromGregorian 2009 8 31 >> >> then how to calculate the day passing 150 days ? >> >> today + 150 doesnot work ! >> > > -- > View this message in context: > http://www.nabble.com/Data.Time-is-so-weak--%21-tp25218462p25218554.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Colin Adams Preston, Lancashire, ENGLAND ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time is so weak ?!
How about: import Data.Time.Calendar import Data.Time.Calendar.WeekDate main = do let (y, w, d) = toWeekDate $ addDays 150 (fromGregorian 2009 8 31) putStrLn $ show d 2009/8/31 zaxis : > > addDays 150 (fromGregorian 2009 8 31) will work. However, how can i get its > weekday from the result ? > > thanks! > > > zaxis wrote: >> >> today = fromGregorian 2009 8 31 >> >> then how to calculate the day passing 150 days ? >> >> today + 150 doesnot work ! >> > > -- > View this message in context: > http://www.nabble.com/Data.Time-is-so-weak--%21-tp25218462p25218554.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Colin Adams Preston, Lancashire, ENGLAND ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time is so weak ?!
addDays 150 (fromGregorian 2009 8 31) will work. However, how can i get its weekday from the result ? thanks! zaxis wrote: > > today = fromGregorian 2009 8 31 > > then how to calculate the day passing 150 days ? > > today + 150 doesnot work ! > -- View this message in context: http://www.nabble.com/Data.Time-is-so-weak--%21-tp25218462p25218554.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data.Time is so weak ?!
today = fromGregorian 2009 8 31 then how to calculate the day passing 150 days ? today + 150 doesnot work ! -- View this message in context: http://www.nabble.com/Data.Time-is-so-weak--%21-tp25218462p25218462.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
