[phobos] Deprecation of std.date

[Jonathan M Davis]

On Sunday 16 January 2011 17:43:35 Jonathan M Davis wrote:
> On Sunday 16 January 2011 11:48:36 Walter Bright wrote:
> > Jonathan M Davis wrote:
> > > Regardless, there will be one function - the version
> > > std.file.lastModified which just takes the file name - which will break
> > > the build of anyone using it, because the only thing changing in its
> > > signature is its return type (SysTime instead of d_time), so there's no
> > > way to overload it. Fortunately, however, I think that it's the only
> > > function in that boat.
> > 
> > It needs to have a different name if its return type changes.
> 
> Okay, then. If that's how you'd prefer to do it, then I guess that that's
> what I'll do - though nothing immediately comes to mind as an alternate
> name for lastModified. I'll have to brainstorm a bit, I guess.

LOL. Oh, how life gets more interesting. Not only is there also creationTime, 
lastAccessTime, and lastWriteTime in DirEntry which must be renamed, but in 
trying to find new names for them, I figured out that creationTime is totally 
wrong on Posix systems. We've been using stat's st_ctime as the creationTime, 
but it _isn't_ the creation time. It's the last time that the _file status_ 
changed  (i.e., owner, group, link count, mode, etc.). stat doesn't _give_ a 
creation time. So, creationTime doesn't actually make any sense on Posix 
systems. LOL. Ouch.

Well, since I have to rename them anyway, it's the perfect time to set 
creationTime down the path of deprecation on Posix systems. I guess that I'll 
add the status change property (whatever I end up calling it) to the Posix side 
as a replacement. Bleh. I was already planning to make some changes some time 
soon from a patch I've had for a while which fixes the lack of symlink support, 
but the more I look at the file stuff, the more stuff that I see pop up which is 
system-specific. *Sigh* Such is life I suppose.

- Jonathan M Davis