I was wondering about the current status of std.gregorian. It's listed on the left hand side of the docs on the digital mars website, but the actual page isn't there. Looking at the current code, there are a lot of functions which are stubbed out with no code other than assert(0). Is anyone actively working on it?

As for its design, it looks like it's holding the number of days as a ulong with nothing more precise than that. I would have expected a time_t or equivalent with the number of seconds or milliseconds since the epoch. So, that makes it look like it doesn't care about anything more precise than days, which would be insanely limiting if it's supposed to be replacing the buggy std.date.

I'm not quite sure what the overall design plan is for std.gregorian, but due to having to deal with various time-related issues at work, I'm 100% convinced that the correct way to write time code is to have _everything_ in UTC until you actually need it in local time, and at that point you do a conversion (likely to a string); the time/date class however would _always_ be in UTC internally. I've seen way too many timezone and DST issues to think that any other way of doing it makes sense. time_t is always in UTC, though unfortunately most of the posix functions (and likely Windows API functions as well) translate to local time when converting time_t to anything else, which makes it quite easy to introduce conversion bugs into code (especially when DST rolls around).

In any case, what's the current game plan for std.gregorian? I'm willing to work on it help is needed, though as I said, I'd be highly interested in a design which retains UTC for everything until you ask for local time (or at minimum really kept its internals as UTC even if most of the functions were giving you information related to local time), and I don't get the impression that that was quite what std.gregorian is currently designed to do (though it doesn't even seem to include seconds, let alone milliseconds, so I'm not quite sure what the goal of std.gregorian is). Honestly, if there is no time stuff in Phobos which always retains its time in UTC, I'm likely to go and write my own which does, because I'm so sick of time-related bugs in the code that I've dealt with.

- Jonathan M Davis

Jonathan M Davis wrote:
> In any case, what's the current game plan for std.gregorian?

I don't think there is one. There's a void to be filled.

Jonathan M Davis <jmdavisprog at gmail.com> wrote:
> As for its design, it looks like it's holding the number of days as a ulong with nothing more precise than that. I would have expected a time_t or equivalent with the number of seconds or milliseconds since the epoch. So, that makes it look like it doesn't care about anything more precise than days, which would be insanely limiting if it's supposed to be replacing the buggy std.date.

I reckon the Date is pure date and time is supposed to be represented by another type (not yet defined?).  I think that a pure date should be represented by 24h time interval though.


> I'm not quite sure what the overall design plan is for std.gregorian, but due to having to deal with various time-related issues at work, I'm 100% convinced that the correct way to write time code is to have _everything_ in UTC until you actually need it in local time, and at that point you do a conversion (likely to a string); the time/date class however would _always_ be in UTC internally. I've seen way too many timezone and DST issues to think that any other way of doing it makes sense. time_t is always in UTC, though unfortunately most of the posix functions (and likely Windows API functions as well) translate to local time when converting time_t to anything else, which makes it quite easy to introduce conversion bugs into code (especially when DST rolls around).

I agree.  UTC and local time must be different in types, or at least timezone and DST information should accompany time data.


Shin

On Saturday 14 August 2010 23:58:17 Shin Fujishiro wrote:
> > I'm not quite sure what the overall design plan is for std.gregorian, but due to having to deal with various time-related issues at work, I'm 100% convinced that the correct way to write time code is to have _everything_ in UTC until you actually need it in local time, and at that point you do a conversion (likely to a string); the time/date class however would _always_ be in UTC internally. I've seen way too many timezone and DST issues to think that any other way of doing it makes sense. time_t is always in UTC, though unfortunately most of the posix functions (and likely Windows API functions as well) translate to local time when converting time_t to anything else, which makes it quite easy to introduce conversion bugs into code (especially when DST rolls around).
> 
> I agree.  UTC and local time must be different in types, or at least timezone and DST information should accompany time data.

If you are ever going to be converting time from one time zone to another, then you need to have the internal time in UTC _always_. When you go to present the time (be it as a string or getting a particular field like hour or whatever), you can do a conversion form the internal UTC to whatever timezone then, but if you try and actually have the time in a timezone other than UTC and then convert it to another timezone (be it UTC or some other timezone), you're going to be in trouble. You can always convert from UTC to another timezone given the information for that timezone (including DST info), but you can't always convert from a timezone that has DST to one that doesn't. The problem is the 1 hour in Spring which doesn't exist and the 1 hour in Fall which happens twice. In particular, if you have between 1:00 and 1:59 on the Sunday in Fall when the time changes, you cannot possibly know _which_ of the two hours you're in. If your times are in UTC, the conversion is easy. But once you're in a timezone with DST, you don't have the necessary information, and you're screwed. I've dealt with enough time and DST issues at work, that I pretty much wish that the whole world lived in UTC - or at minimum that DST didn't exist. It just makes dealing with time in programs a royal pain to get right.

In any case, ideally, whatever we do for time/date in Phobos is in UTC internally and properly handles conversions to other timezones upon request, but it isn't ever actually in another timezone internally.

- Jonathan M Davis

Jonathan M Davis <jmdavisprog at gmail.com> wrote:
> In any case, ideally, whatever we do for time/date in Phobos is in UTC internally and properly handles conversions to other timezones upon request, but it isn't ever actually in another timezone internally.

Thank you for the detailed description!  Now I convinced that the time value must be held in UTC always.

Then, if I understand correctly, the time object must hold a UTC time value alongside timezone information.

struct Time
{
    ulong utc;
    Timezone tz;
}

... and timezone conversions are done by just replacing the tz member.


Shin

On Sunday 15 August 2010 03:17:27 Shin Fujishiro wrote:
> Jonathan M Davis <jmdavisprog at gmail.com> wrote:
> > In any case, ideally, whatever we do for time/date in Phobos is in UTC internally and properly handles conversions to other timezones upon request, but it isn't ever actually in another timezone internally.
> 
> Thank you for the detailed description!  Now I convinced that the time value must be held in UTC always.
> 
> Then, if I understand correctly, the time object must hold a UTC time value alongside timezone information.
> 
> struct Time
> {
>     ulong utc;
>     Timezone tz;
> }
> 
> ... and timezone conversions are done by just replacing the tz member.
> 
> 
> Shin

Yes. That's basically what you do. The key is to never actually convert whatever you're using to hold time (be it a time_t or whatever) into the local time zone. It must stay in UTC.

- Jonathan M Davis

I had an impression(for std.date) like yours in the past, too and made std.time.
However, there was the issue of license with Tango, and it was not
connected to Phobos.
std.gregorian was developed as a substitute, but unfortunately the API
does not even satisfy a matter.
I want something which supplements this lack heartily.


BTW, I showed the stopwatch which used a performance counter at the same time.
This was developed in the totally clean situation that did not take
influence at all of Tango.
If it is possible, I suggest that to remove std.perf(unlisted
module/NOT boost license) and combine my stopwatch module instead.

On Sunday 15 August 2010 04:41:28 SHOO wrote:
> I had an impression(for std.date) like yours in the past, too and made
> std.time. However, there was the issue of license with Tango, and it was
> not connected to Phobos.
> std.gregorian was developed as a substitute, but unfortunately the API
> does not even satisfy a matter.
> I want something which supplements this lack heartily.
> 
> 
> BTW, I showed the stopwatch which used a performance counter at the same
> time. This was developed in the totally clean situation that did not take
> influence at all of Tango.
> If it is possible, I suggest that to remove std.perf(unlisted
> module/NOT boost license) and combine my stopwatch module instead.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Well, stopwatch functionality could be quite useful completely separately from anything representing a date and time, so if you have something good, and it doesn't have licensing issues, I'm all for having it in Phobos. High precision timers can be quite useful.

As for the date and time functionality, I started on an implementation shortly after my initial question yesterday, and I already have more functionality than std.gregorian has completed, though I still have a ways to go. I've never looked at the Tango stuff, so if what I do is acceptable, it won't have the same issues that yours unfortunately did.

When I have something complete enough to be properly useable (though probably not with all of the functionality that we'll eventually want), I'll post it here. I hope to have that within a few days, if not sooner. As it is, I'm likely going to have to implement something similar in C++ for work one of these days soon anyway, so that our newer products won't have the same time issues as the old ones. Historically, we've had to fix time-related bugs just about every time DST rolls around.

- Jonathan M Davis

Thanks for your work, Jonathan. Our decision after the issue with Tango's date and time was to use Boost's. I'd started std.gregorian as a seed of a port of Boost's date and time, in the hope that someone will continue it. Jeff Garland (Boost's date/time author) has been very supportive in the matter.

I very strongly suggest to stick with copying Boost's or C++0x's date and time facilities, unless we find some clearly superior ways facilitated by D's features. Developing our own date/time library from scratch risks of being at best just as capable as Boost/C++0x but guaranteed unfamiliar to everyone.


Andrei

Jonathan M Davis wrote:
> On Sunday 15 August 2010 04:41:28 SHOO wrote:
>> I had an impression(for std.date) like yours in the past, too and made
>> std.time. However, there was the issue of license with Tango, and it was
>> not connected to Phobos.
>> std.gregorian was developed as a substitute, but unfortunately the API
>> does not even satisfy a matter.
>> I want something which supplements this lack heartily.
>>
>>
>> BTW, I showed the stopwatch which used a performance counter at the same
>> time. This was developed in the totally clean situation that did not take
>> influence at all of Tango.
>> If it is possible, I suggest that to remove std.perf(unlisted
>> module/NOT boost license) and combine my stopwatch module instead.
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> Well, stopwatch functionality could be quite useful completely separately from anything representing a date and time, so if you have something good, and it doesn't have licensing issues, I'm all for having it in Phobos. High precision timers can be quite useful.
> 
> As for the date and time functionality, I started on an implementation shortly after my initial question yesterday, and I already have more functionality than std.gregorian has completed, though I still have a ways to go. I've never looked at the Tango stuff, so if what I do is acceptable, it won't have the same issues that yours unfortunately did.
> 
> When I have something complete enough to be properly useable (though probably not with all of the functionality that we'll eventually want), I'll post it here. I hope to have that within a few days, if not sooner. As it is, I'm likely going to have to implement something similar in C++ for work one of these days soon anyway, so that our newer products won't have the same time issues as the old ones. Historically, we've had to fix time-related bugs just about every time DST rolls around.
> 
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Sunday 15 August 2010 05:36:08 Andrei Alexandrescu wrote:
> Thanks for your work, Jonathan. Our decision after the issue with Tango's date and time was to use Boost's. I'd started std.gregorian as a seed of a port of Boost's date and time, in the hope that someone will continue it. Jeff Garland (Boost's date/time author) has been very supportive in the matter.
> 
> I very strongly suggest to stick with copying Boost's or C++0x's date and time facilities, unless we find some clearly superior ways facilitated by D's features. Developing our own date/time library from scratch risks of being at best just as capable as Boost/C++0x but guaranteed unfamiliar to everyone.
> 
> 
> Andrei

Well, I didn't entirely toss out what std.gregorian is up to. I need to look at Boost's stuff in either case, but its internal implementation for date with using the number of days since the beginning of the calendar as its measurement seems to complicate things considerably and end up being less efficient in general. My current implementation is using a split year, month, and day approach. The code is way clearer, and the resulting struct actually takes up less space (6 bytes instead of 8 with all 3 values being shorts or ushorts). Regardless, I'll have to look at Boost's implementation to see exactly what they're up to. My primary concern as a user of a date/time library, however, is that time always be held internally in UTC, and the docs don't give the impression that that's the case for Boost, so if I have a choice in the matter, and they are indeed not keeping time in UTC at all times, I'm going to implement it differently. They're also lacking functions that I've seen in other libraries (like Java) which seem pretty basic - such as the ability to add or subtract months and years to/from a date. So, I'll continue working on it, keeping in mind that you'd like it to more or less follow Boost, and we'll see what you think of it when I'm done. Personally, I'm more familiar with Java's and Qt's libraries, which are a fair bit different from Boost (and different from each other for that matter). I've never used one that I entirely liked though. Regardless, I'd like Phobos' date/time functionality to be powerful, _correct_ (particularly with regards to DST and the like), and user-friendly.

- Jonathan M Davis