nodatime / nodatime Goto Github PK

It would be nice if "round trip" for LocalDate{,Time} parsing really was 
completely round-trip, including calendar - at least for a known set of 
calendars. Currently although formatting and parsing *use* the calendar 
information, it's not part of the textual representation.

We should possibly have a format specifier for "calendar name". It would *at 
least* help when debugging.

We currently don't support a Gregorian/Julian cutover calendar, or the Buddhist 
calendar. I believe we can punt these to post-v1.

Our "fraction" specifier for OffsetPatternParser only handles up to 3 digits. 
We should handle up to 7, as that's how many we can store.

Time zones are fiddly get to right, and errors can be hard to spot.

If we assume that Joda Time is right (or would like to know if we find they've 
got a bug) we can create tools for both Joda Time and Noda Time to spit out all 
the transitions for (say) 1800-2200 in the same format, for all time zones. We 
can then diff the two files, and work out why any differences occur. (There 
will be some, potentially - Joda Time doesn't consider a name-only transition 
to be a transition, for example.)

What steps will reproduce the problem?
1. Try rebuilding any recent tzdb database

What is the expected output? What do you see instead?

Should work. Barfs on 24:00 for Jordan.

What steps will reproduce the problem?
1. Download supplementalData.xml from unicode.ord:

http://unicode.org/repos/cldr/trunk/common/supplemental/supplementalData.xml

2. Run the ZoneInfoCompiler tool, and parse the xml
3. Check the resultant winmap.resx

What is the expected output? What do you see instead?

  The file should have the new data. It's currently effectively empty.

We should have a user guide page to explain how to:
a) Build a new resx/resources file
b) use it from code.

If we're asked to create a pattern of (say) "hh:mm tt" for a culture where the 
AM and PM designators are empty, what should we do? Accept the inappropriate 
ambiguity, or throw an exception?

Currently we treat fractional characters (e.g. '1/2') as digits but then don't 
handle them properly.

We should reject them when considering whether or not they're digits - along 
with anything outside the range 0-9.

Our period arithmetic is simple and predictable, but should be better 
documented before v1.

(This issue will evolve, listing what we believe we need in the user guide 
before v1.)

- When to use which type, and how to convert between them. (Particularly local 
/ zoned)
- Interop with BCL types
- Installation, dependencies etc
- Unit testing best practices

We're out of sync with Gaza and the West Bank until we roll out 2012c.

Currently we prohibit completely empty periods, although we allow periods with 
specified units which are 0 - so "0 days" is okay, but not specifying 
*anything* is not. This creates a number of corner cases - it might be more 
useful to allow empty periods. We should decide this before v1.

What steps will reproduce the problem?
1. Call Duration.ParseExact("35:00", "HH:mm")

What is the expected output? What do you see instead?

I would expect an exception. In fact it parses with no error, and the result 
has the % operator applied to it, to bring it into an appropriate range. I 
can't see why we'd want this.

Useful for generic methods, like NUnit Assert.GreaterThan. It seems that 
semantically Instants should be IComparable, after all they are strictly 
ordered by ticks...

Zone lines that specify days as last[Day] or Day>=N are parsed incorrectly.
It appears that there is no support at all for these kinds of zone lines in 
TzdbZoneInfoParser.ParseZone.
This of course results in errors in time zone conversions.

Currently we only have one satellite assembly - Germany. That doesn't have any 
actual different resources, so we can safely delete it for the moment.

In the long term I want to think about how we can bundle multiple resources in 
NodaTime.dll *and* allow others to provide their own. This also fits somewhat 
with working out the best way of providing out-of-band time zone updates.

The NodaTime.xml we would ship at the moment contains documentation for 
internal members, which is frankly a waste for non-Noda developers.

I believe SHFB has an option to output a stripped version - we should use that.

Consider changing to a "single provider" model for time zones, with a compound 
provider facade.

(This would probably make all kinds of things simpler.)

Currently we have two versions of the solution file - one for VS2008 and one 
for VS2010. They share the C# project files, however.

Unfortunately the "client profile" setting has changed name in the project 
file between 2008 and 2010.

I suspect we'll need to have all kinds of build magic to build the different 
versions anyway, but this is just one to watch out for.

Fixed typo in the Debug/debug folder pattern.

DateTimeZone.GetOffsetFromLocal is documented (as per Joda Time) to return 
the later time when there's a DST cutover. Unfortunately not only is the 
documentation extremely unclear (as it is in Joda); it's also inaccurate.

For example, passing in a local time of 1.30am on November 11th 2009 in 
America/Los_Angeles *should* give an offset of -8 hours, so that the local 
time is treated as 9.30am; in fact -7 is returned, because the transition 
isn't detected.

Here's the Joda Time bug tracking the same issue:
https://sourceforge.net/tracker/index.php?
func=detail&aid=2952991&group_id=97367&atid=617889#

It's possible that I've just misunderstood the docs - but either way, when 
we've worked out what it should do, we should fix the documentation to be 
clearer.

What steps will reproduce the problem?
1. Request conversion of UTC 2000-01-01 01:00:00 to Africa/Khartoum
2.
3.

What is the expected output? What do you see instead?
Expected: 2000-01-01 03:00:00
Get:
NodaTime.TimeZones.CachedDateTimeZone.HashArrayCache.CreateLocalInstantNode(Int3
2 period)

What version of the product are you using? On what operating system?
Built from source taken in November 2010

Please provide any additional information below.

I'd like to be able to include Instants in POCOs which are serialized using a 
DataContractSerializer.

What steps will reproduce the problem?
1. Call Duration.ParseExact("12:64", "HH:mm")

What is the expected output? What do you see instead?
I'd expect this to be an error - we're not really viewing the 64 as some 
arbitrary number; it ought to be in the range [0, 60)

What steps will reproduce the problem?
1. Parse "12.34" with the format "ss.fff" as an offset.

What is the expected output? What do you see instead?
It should be an offset with 12 seconds and 340 milliseconds, but it will 
actually only have 34 milliseconds.

We'd like to be able to use Noda Time on Windows Phone 7.

Initial spiking suggests the following changes are required:

- Conditionalize the use of SerializableAttribute and the extra constructors 
for serialization for exceptions.
- Remove the use of SortedList in TimeZoneCache
- Remove the use of ReaderWriterLock in TimeZoneCache
- Remove use of Encoding.GetString(byte[]) - use the 3-parameter version instead
- Remove use of InvalidDataException, or provide our own on Silverlight.
- Conditionalize which overload of the ArgumentOutOfRangeException is used.
- Conditionalize NodaCultureInfo constructors (no useUserOverride, no LCID)
- Use Name for checking whether the parent is the invariant culture, not LCID
- CultureInfo.GetCultureInfo doesn't exist in Silverlight; remove from 
NodaCultureInfo conditionally?
- DateTimeFormatInfo.{TimeSeparator/DateSeparator} aren't supported in 
Silverlight. This could be fun...
- No obvious way of getting the system time zone in Silverlight
- Replace Array.ConvertAll in UnsupportedDurationField with a hand-written 
implementation
- Enum.GetValues isn't supported, so initializing UnsupportedDurationField will 
be somewhat ugly.

This is all out of the scope of v1.0.

For v1, we should:

- Be able to build on Mono 2.10.8 using xBuild
- Be able to run the unit tests with no failures

What steps will reproduce the problem?
1. Call Duration.TryParse(null)

What is the expected output? What do you see instead?
Expected output: return value of false, output parameter set to 
default(Duration).

Actual output: ArgumentNullException

All Etc/GMT+N timezones have 0 offsets instead of the expected -1, -2, etc.

I've tracked down the bug to the overflow checking code in
ZoneTransition(Instant instant, String name, Offset standardOffset, Offset 
savings), around line 75 in ZoneTransition.cs

These timezones have a transition at BOT and a negative offset, thus the first 
if statement applies. The value of distanceFromEndOfTime is zero, because it 
calculates the distance from the beginning of time. Thus, the standardOffset is 
set to 0.

Also, in the condition of the second if statement, i have a feeling that you 
wanted to use WallOffset instead of savings, but that code doesn't seem to be 
used anyway.

Calculations with diference between workdays and hollydays and weekends. It 
would be great if it could be used in a Fluent Interface Way Such as.

var hollydays = new List<Date>();
hollydays.Add(new HollyDay(1900,12,25, "Christmas"))
hollydays.Add(new HollyDay(1900,1,1, "New Years"))

// returns a integer with number of workdays between one date and another
Calendar.Hollydays(hollidays).DaysBetween (new Date(2010, 12, 01),new 
Date(2011, 01,15)).Workdays

// returns a integer with number of current days between one date and another
Calendar.Hollydays(hollidays).DaysBetween (new Date(2010, 12, 01),new 
Date(2011, 01,15)).AnyDays

// returns a integer with number of weekends and hollydays days between one 
date and another
Calendar.Hollydays(hollidays).DaysBetween (new Date(2010, 12, 01),new 
Date(2011, 01,15)).NotBusinessDays

Calculate number os days in a particular way such as:

//Next day 20 workdays from now
Calendar.Hollydays(hollidays).DateFrom (new Date(2010, 12, 01),20).Workdays

//Next day 20 current days from now
Calendar.Hollydays(hollidays).DateFrom (new Date(2010, 12, 01),20).AnyDays

//Next day 20 not business days from now.
Calendar.Hollydays(hollidays).DateFrom (new Date(2010, 12, 
01),20).NotBusinessDays

It would be great if you could configure hollydays on the app.config and maybe 
on databases.

As you may know, F# has a very sound built-in Units of Measure support 
driven by Andrew Kennedy. JodaTime and JSR-310 inspired by it are widely 
used, but only one of currently 3 common Date/Time APIs for Java.

One superior in many aspects is ICU4J supporting a lot more calendars as 
well as Holidays as opposed to Working Days. Both currently missing from 
JodaTime/JSR-310 proposal. 

Furthermore, F# has got the same Measure and Unit frameworks ICU is based 
on. Microsoft is a Unicode member and listed as participant in ICU4C. 
Thus are there any plans to adopt this or the built-in support for real 
Units of Measure under F#?

Hi,

I use the Period object a lot. You can write it out nicely using ToString(), 
which uses the ISO-8601 duration format.

However, there is no easy method to read it back in, AFAIK.

You should have a Period.Parse() method, or, if you want to support other 
formats, a PeriodPattern class like the LocalTimePattern or InstantPattern.

Joda time has the ISOPeriodFormatter FYI.

Apparently (and verified by Joda Time) Paris had an offset of +0:09:21 hours    
from UTC into March 11th 1911.

Noda Time knows about the first transitions (one in 1891 which was just a 
name change, and then the one mentioned above) but it uses an offset of 0.

I'm looking into the time zone stuff at the moment, but I'm unlikely to get 
to the bottom of this one easily...

Several applications need the idea of a range - I suspect the most common 
case is local dates.

It would be nice if we could use:

    LocalDateRange range = new LocalDateRange(start, end);
    foreach (LocalDate date in range)
    {
    }

We can use the code in MiscUtil (http://pobox.com/~skeet/csharp/miscutil) as 
a starting point for this. We may want to consider whether to "go generic" or 
just include the ranges for the most common cases.

I don't want to ship v1 with anything we know we need to do, but haven't got 
round to :)

There are some CalendarSystem calls for creating LocalInstant values
from year/month/day which don't *appear* to be validating their parameters.

We definitely need to fix this pre-V1, if indeed it's an issue. Ideally, the 
documentation should be updated too.

Eventually we'll want to have strong naming, but it'll take a little while to 
work out what the community needs (key only held by Jon? something else?) - 
suggest we make it post-v1.

SystemClock has an Instance, so that users who use SystemClock.SystemNow can 
get a different implementation... but it can't be changed without reflection.

The API might look like

SystemClock.WithInstance(specialInstance, () => { ... });

or as simple as making SystemClock.Instance settable...

Having just regenerated the TZDB resx with 2012c, we have a discrepancy with 
Joda Time - Noda Time doesn't generate any transitions after 2011. Looking into 
it...

(From a mail.)

Currently DateTimeZones.Ids throws System.ArgumentException : An entry
with the same key already exists.
The reason is that it tries to add UTC twice - first time before
entering loop, and then in foreach loop.

Currently in some situations we use the culture-sensitive decimal separator for 
fractions of seconds; it looks like we should always use . based on the BCL, 
Java standard library and Joda Time behaviour.

Changing the values in a NodaFormatInfo can change how parsing works. When 
caches are used, this messes things up. We shouldn't use caching when using a 
non-readonly format info.

- We don't use the "T" part to separate date from time parts
- We use the wrong designator for minutes and seconds
- We could handle partial seconds in an ISO-friendly way, with potential data 
loss.

Even if we don't get round to the parser for V1, I want the formatting to be 
fixed...

Before we hit v1, we should go over the whole documented API, member by member, 
and make sure it makes sense, has appropriate names, doesn't expose anything we 
don't want etc.

Unicode CLDR (http://cldr.unicode.org/) has quite a bit of mapping information 
which would be useful for time zones, such as an appropriate form in which to 
present them to users. It would be nice to make this information available 
through Noda Time.

This feature will require quite a bit of investigation, especially to consider 
how it might fit with non-zoneinfo time zone providers.

Currently we do support time zone aliases, but all aliases are created equal - 
so there's no way of telling which of (say) Africa/Timbuktu or Africa/Bamako is 
the canonical form.

Options:
- Leave the canonical ID in the zone, so if you ask for an alias you get the 
exact same time zone object as the canonical one.
- Build separate objects, but have both the alias and the ID as properties
- Expose an alias map separately in the provider

Consider the following code:

var localDateTime = new LocalDateTime(2011, 11, 9, 1, 30); //2011-11-09 1: 30 AM
var timeZone = DateTimeZone.ForId("America/New York");
var dateInfo = timeZone.MapLocalDateTime(localDateTime);

2011-11-09 at 1:30 AM in the America/New York timezone should be an 
"unambiguous" time, yet the 'Type' property on the dateInfo instance above is 
returning 'Ambiguous' in this case. In addition, the 'UnambiguousMapping' 
property is returning a valid value, even though it technically should be 
throwing an InvalidOperation exception because the mapping is supposedly 
ambiguous. Similarly, the 'EarlierMapping' and 'LaterMapping' properties both 
throw invalid operation exceptions.

Additionally, using a truly ambiguous date, like 2011-11-06 at 1:30 AM (falls 
into the change back from daylight savings in Eastern US timezone), it also 
reports the Type of the local date mapping as "ambiguous", but correctly throws 
an invalid operation exception for the 'UnambiguousMapping' property but 
returns correct values for the EarlierMapping and LaterMapping properties.

It seems like there's a bug where the 'Ambiguous' type is set for both 
ambiguous and unambiguous dates in the MapLocalDateTime function.

As of CLDR v2, windowsZones.xml contains multiple mappings per name rather than 
just one. We'll need to work out how to handle this.

To make it simpler to diagnose problems, we should make time zone providers 
specify some sort of identifier - e.g. "zoneinfo - 2011n". The ZoneInfoCompiler 
can probably infer these from the directory in most cases.