On 2012-05-24 14:46, Stephen Colebourne
described some Microsoft .NET datetime functions:
> I've had a quick look at the .NET API
> Uses properties Year, Month (int-based), Day, DayOfWeek (enum-based),
> DayOfYear, Hour, Minute, Second, Millisecond
> Also, "Date" removes the time part, and "TimeOfDay" returns a TimeSpan
> object. "Ticks" returns a cimple count of 100 nanosecond-based ticks.
> There are specific add methods - "AddYears", "AddMonths", "AddDays",
> "AddHours", "AddMinutes", "AddSeconds", "AddMilliseconds"
> There is the ability to add a TimeSpan to a date, or subtract two
> date-times to get a TimeSpan. (TimeSpan is an ISO period type object
> with fields for days, hour,s minutes, seconds and ticks)
> The DateTime object can be created using an alternate calendar system,
> but does not appear to remember that calendar. The Day/Month/Year
> properties always return the ISO/Gregorian day/month/year. To get the
> date in the alternate calendar you have to use a method on the
> DateTime is roughly equivalent to our LocalDateTime and LocalDate.
> DateTimeOffset is roughly equivalent to our OffsetDateTime and OffsetDate.
Just an addition on the concept of DateTimes in .NET:
Microsoft's DateTime values not only encode a datetime with 0.1 µs
resolution, covering G0001-01-01 until G10000-01-01 - 0.1 µs, they
also comprise a "kind" that indicates whether the datetime is
a UTC value, or a local time, or of an "unspecified" kind. The
"kind" is encoded in the most significant bits of 64 bit DateTimes.
It is used and modified by conversion functions between local
At first sight, this looks similar to the distinction between the
types TIMESTAMP WITH LOCAL TIME ZONE and TIMESTAMP WITHOUT TIME ZONE
in Oracle SQL, where the latter type does not suffer from
any -- well-meant but sometimes annoying -- implicit
conversion between server time and local session time as the
former type, so that TIMESTAMP WITHOUT TIME ZONE can be safely used
to store values of a time scale like TDB or TAI (where there simply
are no time zones).
But implicit conversions seem to occur in any case. They just
depend on the "kind", making DateTime usage even more complex: