nodatime / nodatime Goto Github PK
View Code? Open in Web Editor NEWA better date and time API for .NET
Home Page: https://nodatime.org
License: Apache License 2.0
A better date and time API for .NET
Home Page: https://nodatime.org
License: Apache License 2.0
Our period arithmetic is simple and predictable, but should be better
documented before v1.
Original issue reported on code.google.com by jonathan.skeet
on 7 Feb 2012 at 8:07
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...
Original issue reported on code.google.com by jonathan.skeet
on 19 Feb 2010 at 3:13
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.
Original issue reported on code.google.com by jonathan.skeet
on 22 Jan 2012 at 8:55
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.
Original issue reported on code.google.com by jonathan.skeet
on 5 Apr 2012 at 11:08
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
Original issue reported on code.google.com by jonathan.skeet
on 7 Feb 2012 at 8:11
- 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...
Original issue reported on code.google.com by jonathan.skeet
on 18 Mar 2012 at 8:08
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
Original issue reported on code.google.com by jonathan.skeet
on 28 Jan 2012 at 9:01
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.
Original issue reported on code.google.com by jonathan.skeet
on 15 Feb 2012 at 7:39
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?
Original issue reported on code.google.com by jonathan.skeet
on 26 Sep 2011 at 7:03
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.
Original issue reported on code.google.com by jonathan.skeet
on 7 Feb 2012 at 8:18
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.
Original issue reported on code.google.com by jonathan.skeet
on 21 Mar 2012 at 8:04
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.
Original issue reported on code.google.com by [email protected]
on 10 Dec 2011 at 3:22
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.
Original issue reported on code.google.com by jonathan.skeet
on 20 Aug 2011 at 10:57
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...
Original issue reported on code.google.com by jonathan.skeet
on 5 Apr 2012 at 12:45
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.
Original issue reported on code.google.com by [email protected]
on 19 Jan 2011 at 3:28
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.
Original issue reported on code.google.com by jonathan.skeet
on 15 Oct 2011 at 10:24
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...
Original issue reported on code.google.com by [email protected]
on 23 Sep 2011 at 2:03
We're out of sync with Gaza and the West Bank until we roll out 2012c.
Original issue reported on code.google.com by jonathan.skeet
on 4 Apr 2012 at 5:36
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.
Original issue reported on code.google.com by [email protected]
on 28 Dec 2011 at 4:03
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.
Original issue reported on code.google.com by jonathan.skeet
on 13 Jul 2011 at 8:43
I'd like to be able to include Instants in POCOs which are serialized using a
DataContractSerializer.
Original issue reported on code.google.com by [email protected]
on 25 Oct 2011 at 9:10
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.
Original issue reported on code.google.com by jonathan.skeet
on 15 Feb 2012 at 11:33
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.
Original issue reported on code.google.com by jonathan.skeet
on 17 Feb 2010 at 6:26
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.
Original issue reported on code.google.com by jonathan.skeet
on 4 Dec 2009 at 8:09
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.
Original issue reported on code.google.com by jonathan.skeet
on 13 Jul 2011 at 8:40
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.)
Original issue reported on code.google.com by jonathan.skeet
on 26 Jan 2012 at 10:10
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.
Original issue reported on code.google.com by [email protected]
on 16 Jun 2010 at 6:49
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
Original issue reported on code.google.com by jonathan.skeet
on 18 Aug 2011 at 5:31
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.
Original issue reported on code.google.com by jonathan.skeet
on 9 Nov 2009 at 9:16
(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
Original issue reported on code.google.com by jonathan.skeet
on 7 Feb 2012 at 8:16
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.
Original issue reported on code.google.com by jonathan.skeet
on 28 Jan 2012 at 9:04
We currently don't support a Gregorian/Julian cutover calendar, or the Buddhist
calendar. I believe we can punt these to post-v1.
Original issue reported on code.google.com by jonathan.skeet
on 7 Feb 2012 at 8:05
Consider changing to a "single provider" model for time zones, with a compound
provider facade.
(This would probably make all kinds of things simpler.)
Original issue reported on code.google.com by jonathan.skeet
on 22 Jan 2012 at 8:54
We should have a user guide page to explain how to:
a) Build a new resx/resources file
b) use it from code.
Original issue reported on code.google.com by jonathan.skeet
on 4 Apr 2012 at 5:37
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.
Original issue reported on code.google.com by jonathan.skeet
on 7 Feb 2012 at 8:09
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.
Original issue reported on code.google.com by jonathan.skeet
on 25 Sep 2011 at 12:41
I don't want to ship v1 with anything we know we need to do, but haven't got
round to :)
Original issue reported on code.google.com by jonathan.skeet
on 12 Feb 2012 at 12:53
Useful for generic methods, like NUnit Assert.GreaterThan. It seems that
semantically Instants should be IComparable, after all they are strictly
ordered by ticks...
Original issue reported on code.google.com by [email protected]
on 23 Sep 2011 at 2:10
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.
Original issue reported on code.google.com by jonathan.skeet
on 15 Sep 2011 at 5:20
(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.
Original issue reported on code.google.com by jonathan.skeet
on 21 Jun 2010 at 4:43
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.
Original issue reported on code.google.com by jonathan.skeet
on 20 Aug 2011 at 11:00
Fixed typo in the Debug/debug folder pattern.
Original issue reported on code.google.com by [email protected]
on 4 Feb 2011 at 2:37
Attachments:
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.
Original issue reported on code.google.com by jonathan.skeet
on 10 Nov 2011 at 8:36
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.
Original issue reported on code.google.com by [email protected]
on 26 Sep 2011 at 8:31
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.
Original issue reported on code.google.com by [email protected]
on 10 Nov 2011 at 2:52
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#?
Original issue reported on code.google.com by [email protected]
on 7 Apr 2010 at 4:33
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.
Original issue reported on code.google.com by jonathan.skeet
on 15 Sep 2011 at 5:30
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.
Original issue reported on code.google.com by jonathan.skeet
on 7 Feb 2012 at 8:06
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)
Original issue reported on code.google.com by jonathan.skeet
on 20 Aug 2011 at 10:58
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.
Original issue reported on code.google.com by [email protected]
on 1 Mar 2012 at 1:16
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.