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
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
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
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
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
On Saturday, July 2, 2011, Joe Healy j...@omc-international.com.au 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
On Sat, 2011-07-02 at 12:43 +0200, Erik Hesselink wrote:
On Saturday, July 2, 2011, Joe Healy j...@omc-international.com.au 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
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
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]
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
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
On Mon, 27 Jun 2011 11:15:28 +0300
Yitzchak Gale g...@sefer.org 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
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
-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
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
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 z_a...@163.com:
addDays 150 (fromGregorian 2009 8 31) will work. However, how can i get its
weekday from
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 z_a...@163.com:
addDays 150 (fromGregorian 2009 8 31) will work. However, how can i get its
weekday from
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 z_a...@163.com:
addDays 150
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.
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:
20 matches
Mail list logo
