On Sun, 2011-10-23 at 06:11 +0200, Michael Snoyman wrote:

and I think UTCTime is the right data type.

Btw, why do You think UTCTime is more appropriate than POSIXTime? Don't the underlying system calls ({,f,l}stat(2)) actually return `time_t` values for the `st_{a,m,c}time` fields which are supposed to mean "seconds since the Epoch"? -- hvr

On Mon, 2011-10-24 at 09:14 +0200, Michael Snoyman wrote:

...

Btw, why do You think UTCTime is more appropriate than POSIXTime?

Don't the underlying system calls ({,f,l}stat(2)) actually return `time_t` values for the `st_{a,m,c}time` fields which are supposed to mean "seconds since the Epoch"?

I'm talking from a library user perspective. I don't think I've once used POSIXTime, whereas I use UTCTime regularly. Having to deal with just the one type would be very convenient.

I agree it would be convenient to have a `getModificationTime` version where you don't have to prepend a `liftM posixSecondsToUTCTime .` for the cases where you don't care about leap-seconds ...

I think your implication is that it will be more efficient to retrieve these values as POSIXTime.

that and more importantly the correctness issue of the POSIXTime <-> UTCTime not being bijective in case of leap-seconds, see also http://en.wikipedia.org/wiki/Unix_time#Encoding_time_as_a_number for examples where the mapping has discontinuities I.e., the identities utcTimeToPOSIXSeconds . posixSecondsToUTCTime = id posixSecondsToUTCTime . utcTimeToPOSIXSeconds = id are not supposed to hold (I haven't checked the actual implementation in the `time` package, so it might currently hold incorrectly hold in the implementation)

If that's the case, maybe it makes sense to provide two sets of functions. But I definitely would find it an inconvenience to have to deal with POSIXTime myself.

I am in favor for providing also UTCTime wrappers, but I'd definitely want to be able to work with the "natural" representation POSIXTime, in order to avoid information loss in cases where this might matter. E.g., say we get a `setModificationTime` function, then I wouldn't want to have to transform back and forth to UTCTime, if I had code like tsave <- getModificationTime fname modifyFileSomeWay fname setModificationTime fname tsave I'd want the `time_t` value to be exactly the same it was before the modification and not risk being shifted by one in case of leap-seconds. (Or e.g. if I wanted to implement an archiver like `tar` in Haskell, I'd want the original `time_t` value to be restored) -- hvr

Ian Lynagh wrote:

Overall, UTCTime is sounding like the best type to me.

+1 for the change +1 for UTCTime Thanks, Yitz

Edward Kmett wrote:

+1 to both for me as well, though I'd be more comfortable if the orphans could be fixed.

Oh, yes, also +1 for fixing the orphan instances in the time library. Please. Thanks, Yitz

On 25 October 2011 19:29, Ashley Yakeley wrote:

On Tue, 2011-10-25 at 17:13 +0200, Yitzchak Gale wrote:

...

Edward Kmett wrote:

...

+1 to both for me as well, though I'd be more comfortable if the orphans could be fixed.

Oh, yes, also +1 for fixing the orphan instances in the time library. Please.

I could unexpose everything besides Data.Time, I guess.

But that would still leave it orphaned. The only solution is to put UTCTime and its Show instance in the same module (which would probably be some hidden Internal module where parts of it are re-exported from public modules). Bas

On 25 October 2011 19:45, Ashley Yakeley wrote:

On Tue, 2011-10-25 at 19:42 +0200, Bas van Dijk wrote:

...

...

I could unexpose everything besides Data.Time, I guess.

But that would still leave it orphaned.

I don't think so? One would not be able to import any type from time without also importing all its class instances.

-- Ashley

Sorry, you're right, I misinterpreted your message. However, I do like how you currently modularized your package. I could imagine it would be slightly daunting to have all types and functions exposed in one haddock page. Bas

On Tue, Oct 25, 2011 at 04:21:47PM -0700, Brandon Moore wrote:

...

...

But that would still leave it orphaned.

Visiting one extra module (if it could even be avoided)

I'm not sure I understand the problem. As far as I can see, "instance Show UTCTime" is in Data.Time.LocalTime.LocalTime because that module uses UTCTime to define functions like utcToLocalTime, and thus Data.Time.Clock.UTC can't import Data.Time.LocalTime.LocalTime. But couldn't those functions be moved to Data.Time.Clock.UTC and the import reversed? Some other imports and functions may need to be changed around too. I had a quick look, but I'm not familiar enough with the hierarchy to be able to do this all quickly. Thanks Ian

On Sun, 2011-10-23 at 06:11 +0200, Michael Snoyman wrote:

Perhaps this belongs in a separate discussion, but is there any plan to have time provide the locale stuff directly instead of our code needing to depend on old-locale? If I'm not mistaken, implementing such a strategy at the same time would mean that user code could then ignore two old-* packages.

No, locale is not part of time. Nor am I interested in taking responsibility for it. According to http://www.haskell.org/haskellwiki/Library_submissions , old-locale is "maintained only for backward compatibility". And yet no-one can tell me where any new "locale" package is or why the old "locale" became "old-locale" or what might count as "forward" compatibility. Nor do I know of any particular problems with it, but then I haven't examined its subject area particularly closely. TBH I believe the best course of action is to consider old-locale not to be "old" or deprecated in any way, and for the libraries list to continue to maintain it like any other package, should issues arise. Of course, if anyone has some grand idea to replace it with a new "locale", that can be considered too. -- Ashley Yakeley

On Mon, Oct 24, 2011 at 14:08, Jason Dagit wrote:

On Mon, Oct 24, 2011 at 12:53 AM, Ashley Yakeley wrote:

...

On Sun, 2011-10-23 at 06:11 +0200, Michael Snoyman wrote:

...

Perhaps this belongs in a separate discussion, but is there any plan to have time provide the locale stuff directly instead of our code needing to depend on old-locale? If I'm not mistaken, implementing such a strategy at the same time would mean that user code could then ignore two old-* packages.

No, locale is not part of time. Nor am I interested in taking responsibility for it.

According to http://www.haskell.org/haskellwiki/Library_submissions , old-locale is "maintained only for backward compatibility". And yet no-one can tell me where any new "locale" package is or why the old "locale" became "old-locale" or what might count as "forward" compatibility. Nor do I know of any particular problems with it, but then I haven't examined its subject area particularly closely.

I've tripped on this as well. Putting 'old-foo' in a cabal file feels wrong, but when I looked I also couldn't find any discussion as to why it is called old-locale.

My understanding is [old-]locale was used only by [old-]time; it was intended to gather various locale dependent things, but never did. So when time was deprecated to old-time, locale went along with its only consumer. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On 25 October 2011 14:40, Yitzchak Gale wrote:

I propose that we change the name of old-locale to time-locale.

+1 But what does this mean in practice? Does it mean we deprecate old-locale in favor of a new package time-locale? (It would be nice if cabal would emit a warning when depending on a deprecated package, just like DEPRECATE pragmas for functions do) What does this mean for the Haskell Platform? Do we add time-locale? Removing old-locale is problematic since a number of packages in the HP depend on it: haskell98 hpc old-time time cgi But it's probably best to just update these packages to work with time and time-locale.

Independently of my proposal to change the name, I also propose that the package description and module haddock comment be changed to state clearly what this package is and is not.

+1 Regards, Bas

On 25 October 2011 19:47, Ashley Yakeley wrote:

I wrote:

...

No, locale is not part of time. Nor am I interested in taking responsibility for it.

Actually, I suppose this depends on whether we still need to expose a "System.Locale". If not, probably better for the time package to not depend on old-locale and instead create a new type for time locale

That would be really nice!

under Data.Time.LocalTime.

Isn't it better to export TimeLocale from Data.Time.Format since that's the only place where it's used? Regards, Bas

I agree with all that Bas and Ashley wrote. If Ashley agrees to put TimeLocale into D.T.F, I withdraw my two proposals and we'll all celebrate. We can deprecate old-locale and issue a last version that just re-exports from D.T.F. We'll leave it in the platform until the handful of other platform packages using it migrate to D.T.F, then remove it from the platform. User code that hasn't been able to migrate by then can still be compiled by installing old-locale from hackage. And yes, I agree that a mechanism for deprecation warnings via cabal would be really nice. Thanks, Yitz

TimeLocale is now in Data.Time.Format, in time-1.5. -- Ashley On 2013-06-16 08:39, David Virebayre wrote:

Hello,

I've very sorry to revive such an old discussion, but I was wordering if there was any follow up to this discussion ? It doesn't look like TimeLocale ended up in Date.Time.LocalTime, and time-locale doesn't exist.

I have to compare two dates, one coming from a string I have to parse, the other from a file's modification time. I was looking for a way to get rid of the old-locale dependency; though at this point it's not that important.

Thanks,

David.

2011/10/25 Yitzchak Gale :

...

I agree with all that Bas and Ashley wrote.

If Ashley agrees to put TimeLocale into D.T.F, I withdraw my two proposals and we'll all celebrate.

We can deprecate old-locale and issue a last version that just re-exports from D.T.F. We'll leave it in the platform until the handful of other platform packages using it migrate to D.T.F, then remove it from the platform.

User code that hasn't been able to migrate by then can still be compiled by installing old-locale from hackage.

And yes, I agree that a mechanism for deprecation warnings via cabal would be really nice.

Thanks, Yitz

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

+1 Sent from my iPhone On Oct 24, 2011, at 5:47 AM, Jon Fairbairn wrote:

Ian Lynagh writes:

...

This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general.

+1

The present state of affairs annoys me every time I want to deal with file modification times.

...

I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know?

I think the library definition ought not to rely on platform-specific time representations¹. Apropos the question of avoiding information loss, can the library have implementation specific work-arounds? Something like on POSIX systems, have UTCTime have an extra (secret) field that provides sufficient information to turn it back to the system representation.

[1] and I’m saying this from the point of view of someone who uses unix-type systems almost exclusively.

-- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2010-09-14)

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Sat, Jan 14, 2012 at 09:09:23PM +0000, Thomas Schilling wrote:

On 14 January 2012 19:43, Ian Lynagh wrote:

...

On Sat, Oct 22, 2011 at 10:28:08PM +0100, Ian Lynagh wrote:

...

This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general.

I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know?

Applied, using UTCTime:

08894f96407635781a233145435a78f144accab0 in ghc d0cab4bb327910a341bc99f4e8539806bd671a11 in directory a73b30e1b9d6d45fc44a4269535697018ec4881a in directory dd3ba275911a897c421ca084057aad76c38bd4a5 in hpc

Is there a fallback to platform-specific types for those who need it?

Just the pre-existing withFileStatus/modificationTime on Windows, and getFileStatus/modificationTime on unix.

I know that came up a while ago on a different matter and I think it's reasonable to provide both the standard high-level API and a lower-level API.

Any low-level API should probably be in unix/Win32, with directory's high-level API calling it. Thanks Ian