Proposal for custom time string formatting in std.datetime

[Jonathan M Davis]

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