Proposal for custom time string formatting in std.datetime

[Jacob Carlborg]

On 2011-12-23 03:38, Jonathan M Davis wrote:
> On Thursday, December 22, 2011 13:38:51 Andrei Alexandrescu wrote:
>> On 12/22/11 1:32 PM, Jonathan M Davis wrote:
>> [snip]
>>
>> Now that we got to talk about std.datetime, here are three things that I
>> think we could do to make it more manageable.
>>
>> 1. Put files in data. I find it a tad awkward that we have time zone
>> information in hardcoded strings inside the code. That means any such
>> change would have us redistributed Phobos. I'm thinking a small data
>> file would be more appropriate. Better yet, hook into OSs timezone
>> information and let the OS worry about keeping that timely.
>
> The only reason there are any hard-coded time zone names is that they're
> required to convert between the names used by Posix and those used by Windows.
> So, you _can't_ hook into the OS information and get them. Now, conceivably,
> you could move that information into a file and then parse the file when it's
> needed. That would obviously be less efficient, but creating a WindowsTimeZone
> or PosixTimeZone (which is what they'd most frequently be needed for) isn't
> exactly terribly efficient to begin with, since you have to read in the time
> zone information from from the disk or from the registry (which is probably on
> disk). So, that's not unreasonable.
>
>> 2. datetime == time + date. We could reduce std.datetime to "public
>> import std.time, std.date;" and define:
>>
>> (a) std.time ->  everything having to do with sheer time information, no
>> date-related oddities. That means the largest formalized interval would
>> be the week.
>>
>> (b) std.date ->  all of the bizarre calendar stuff, dealing with months
>> and more. Naturally std.date would use std.time.
>
> Well, the only time point type which only deals with time and not dates is
> TimeOfDay. Date, DateTime, and SysTime all deal with dates. You can't really
> get away from dealing with dates once your type holds more than 24 hours worth
> of time unless it's a duration as opposed to a time point. So, I really don't
> think that trying to split std.datetime into std.date and std.time makes much
> sense.
>
> A better division would be to put SysTime in a module and TimeOfDay, Date, and
> DateTime in another. SysTime deals with the system time, has a time zone, and
> is intended for use with stuff which isn't calendar-based (timestamps and file
> times being good examples - anything where you need the absolute time when it
> occured), whereas the others don't have a time zone and therefore _are_
> calendar-based. However, they all share common code, so they'd either need to
> duplicate that code or any modules that they're split up into need to be in
> the same package. They _could_ both be sitting in std directly, but that would
> give package access to completely unrelated functions. It's also possible that
> we'll have more date and/or time related modules in the future (for instance,
> having one for handling date-recurrence patterns would be nice), and if that
> occurs, it makes that much more sense to use a sub-package rather than std.
>
> If we're splitting it up, there's also the question of how far we want to
> split it up. In the extreme case, we could put every struct and class in its
> own module, though that's going too far IMHO. But we're probably going to want
> to go farther than just splitting it in two. In addition to the benchmarking
> functionality, I'd like to see the time interval and range functionality in a
> separate module, and there's the question of whether the time zone stuff should
> be in its own module - though there's not  much point to the time zones
> without SysTime, so I'm not sure whether that's really valuable.
>
> In any case, if we keep std.datetime and have it publicly import the other
> modules, we can split it up more or less however we like, but having a sub-
> package would make the most sense IMHO. My original std.datetime proposal was
> that way, but it was split badly, and we didn't really have any sub-package
> stuff in Phobos beyond the C stuff and Windows stuff at the time, but that has
> been slowly changing.
>
> - Jonathan M Davis

I think a sub-package would be nice for all time and date related code.

-- 
/Jacob Carlborg