Proposal: Use time rather than old-time in directory

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal: Use time rather than old-time in directory

Ian Lynagh

Hi all,

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?

I started off with UTCTime, then switched to POSIXTime as UTCTime didn't
have a Show instance. I've since found that actually UTCTime has both
Show and Read instances, but they are orphaned. So actually, if UTCTime
is the better type then switching back to UTCTime would allow us to fix
this comment in hpc:
-- We would rather use ClockTime in Mix, but ClockTime has no Read instance
and simplify the code slightly.


Attached are patches for directory, hpc and ghc.


Suggested discussion period: Until 5th Nov 2011.


Thanks
Ian


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

0001-Use-time-POSIXTime-rather-than-old-time-ClockTime.patch (2K) Download Attachment
0001-Use-time-POSIXTime-rather-than-old-time-ClockTime.patch (1K) Download Attachment
0001-Use-time-POSIXTime-rather-than-old-time-ClockTime.patch (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Michael Snoyman
On Sat, Oct 22, 2011 at 11:28 PM, Ian Lynagh <[hidden email]> wrote:

>
> Hi all,
>
> 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?
>
> I started off with UTCTime, then switched to POSIXTime as UTCTime didn't
> have a Show instance. I've since found that actually UTCTime has both
> Show and Read instances, but they are orphaned. So actually, if UTCTime
> is the better type then switching back to UTCTime would allow us to fix
> this comment in hpc:
> -- We would rather use ClockTime in Mix, but ClockTime has no Read instance
> and simplify the code slightly.
>
>
> Attached are patches for directory, hpc and ghc.
>
>
> Suggested discussion period: Until 5th Nov 2011.
>
>
> Thanks
> Ian

+1. I'd like to transition to a single package as much as possible,
and I think UTCTime is the right data type.

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.

Michael

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Herbert Valerio Riedel
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


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Vincent Hanquez
In reply to this post by Michael Snoyman
On 10/23/2011 05:11 AM, Michael Snoyman wrote:

> On Sat, Oct 22, 2011 at 11:28 PM, Ian Lynagh<[hidden email]>  wrote:
>> Hi all,
>>
>> 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?
>>
>> I started off with UTCTime, then switched to POSIXTime as UTCTime didn't
>> have a Show instance. I've since found that actually UTCTime has both
>> Show and Read instances, but they are orphaned. So actually, if UTCTime
>> is the better type then switching back to UTCTime would allow us to fix
>> this comment in hpc:
>> -- We would rather use ClockTime in Mix, but ClockTime has no Read instance
>> and simplify the code slightly.
>>
>>
>> Attached are patches for directory, hpc and ghc.
>>
>>
>> Suggested discussion period: Until 5th Nov 2011.
>>
>>
>> Thanks
>> Ian
> +1. I'd like to transition to a single package as much as possible,
> and I think UTCTime is the right data type.
+1 to transition to a single package.
> 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.
I agree, this is quite confusing to have to get things from a "old-" package in
the time package and even more that there's no "new" package for old-locale.

--
Vincent

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Michael Snoyman
In reply to this post by Herbert Valerio Riedel
On Sun, Oct 23, 2011 at 12:30 PM, Herbert Valerio Riedel <[hidden email]> wrote:
> 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"?

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 think your implication is that it will be more efficient to retrieve
these values as POSIXTime. 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.

Michael

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

old-locale

Ashley Yakeley
In reply to this post by Michael Snoyman
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


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Ashley Yakeley
In reply to this post by Ian Lynagh
On Sat, 2011-10-22 at 22:28 +0100, Ian Lynagh wrote:
> Hi all,
>
> 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?

Probably you want UTCTime. If it's possible to use directory on a
non-POSIX system, then definitely UTCTime.

BTW folks, I haven't forgotten the realToFrac optimisation and expect to
have a look at it on the weekend.

-- Ashley


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Herbert Valerio Riedel
In reply to this post by Michael Snoyman
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


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Herbert Valerio Riedel
In reply to this post by Ian Lynagh
On Sat, 2011-10-22 at 22:28 +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.

+1 (regardless of what is decided w.r.t. POSIXTime vs. UTCTime)

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


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Jon Fairbairn
In reply to this post by Ian Lynagh
Ian Lynagh <[hidden email]> 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                                 [hidden email]
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2010-09-14)


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Edward Kmett-2
+1

Sent from my iPhone

On Oct 24, 2011, at 5:47 AM, Jon Fairbairn <[hidden email]> wrote:

> Ian Lynagh <[hidden email]> 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                                 [hidden email]
> http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2010-09-14)
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Bas van Dijk-2
In reply to this post by Ian Lynagh
+1

On 22 October 2011 23:28, Ian Lynagh <[hidden email]> wrote:
> I started off with UTCTime, then switched to POSIXTime as UTCTime didn't
> have a Show instance. I've since found that actually UTCTime has both
> Show and Read instances, but they are orphaned.

Ashley, is it possible you could de-orphan the Show instance for
UTCTime? This has bitten me a few times in the past since I normally
don't import Data.Time (which would give me a Show instance for
UTCTime) but use Data.Time.Clock directly.

I understand you have to shuffle with modules a bit since the Show
instance is currently exported from the hidden module
Data.Time.LocalTime.LocalTime which itself is exported from
Data.Time.LocalTime.

Regards,

Bas

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: old-locale

Jason Dagit-3
In reply to this post by Ashley Yakeley
On Mon, Oct 24, 2011 at 12:53 AM, Ashley Yakeley <[hidden email]> 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.

Jason

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Ian Lynagh
In reply to this post by Herbert Valerio Riedel
On Mon, Oct 24, 2011 at 10:10:23AM +0200, Herbert Valerio Riedel wrote:

>
> 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.

I think this is OK in the positive leap second case:

There is an ambiguous POSIX timestamp on the FS.
We convert that to one of the two possible UTCTimes.
We convert it back to the ambiguous POSIX timestamp.

In the negative leap second case, it's only a problem if the POSIX
timestamp is a time that never happened. Even then it's idempotent at
least.

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


Thanks
Ian


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: old-locale

Brandon Allbery
In reply to this post by Jason Dagit-3
On Mon, Oct 24, 2011 at 14:08, Jason Dagit <[hidden email]> wrote:
On Mon, Oct 24, 2011 at 12:53 AM, Ashley Yakeley <[hidden email]> 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                                      [hidden email]
wandering unix systems administrator (available)     (412) 475-9364 vm/sms


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Yitzchak Gale
In reply to this post by Ian Lynagh
Ian Lynagh wrote:
> Overall, UTCTime is sounding like the best type to me.

+1 for the change
+1 for UTCTime

Thanks,
Yitz

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: old-locale

Yitzchak Gale
In reply to this post by Ashley Yakeley
Ashley Yakeley wrote:
> 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.

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

It is a very simple, harmless package, containing only a data type
representing the locale information needed by the time package.
It has no dependence on any other locale or i18n infrastructure.

But the name, besides being wrong, sounds very scary.
Locale is a huge, complex issue and a moving target.
And this is "old", to boot. From the name, you would be
almost certain that this package involves serious problems.

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.

Thanks,
Yitz

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Edward Kmett-2
In reply to this post by Yitzchak Gale
+1 to both for me as well, though I'd be more comfortable if the orphans could be fixed.

Sent from my iPhone

On Oct 25, 2011, at 8:24 AM, Yitzchak Gale <[hidden email]> wrote:

> Ian Lynagh wrote:
>> Overall, UTCTime is sounding like the best type to me.
>
> +1 for the change
> +1 for UTCTime
>
> Thanks,
> Yitz
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Use time rather than old-time in directory

Yitzchak Gale
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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: old-locale

Bas van Dijk-2
In reply to this post by Yitzchak Gale
On 25 October 2011 14:40, Yitzchak Gale <[hidden email]> 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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
12