[Mono-dev] why does DateTime.Now.IsDaylightSavingTime() returns false when it should be true.
I am trying to figure out why exactly running
DateTime.Now.IsDaylightSavingTIme() returns false.
I live in the Auckland/Pacific timezone and pretty much everywhere I
look it confirms that yes it is daylight saving time.
Jump to [1] if you want to see what my system looks like.
I have been able to track down the issue I believe to somewhere either
in ical.c ( ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData to
be exact) or CurrentSystemTimeZone. Or potentially a combo of both?
icall GetTimeZoneData seems to be returning its data in the incorrect
order. I have attempted to confirm for a +13GMT southern hemisphere
timezone (TZ=Australia/Sydney) but the results seem to suggest that
using TZ isn't supported. I am therefore unable to determine whether
this is for +13GMT specifically or for some other reason.
Basically I have writing the following unit test to confirm the data
coming from ical_...GetTimeZoneData.
{code}
delegate bool GetTimeZoneDataInternal (int year, out Int64[]
data, out string[] names);
GetTimeZoneDataInternal getTimeZoneData;
[Test]
public void GetTimeZoneData() {
TimeZone t = TimeZone.CurrentTimeZone;
getTimeZoneData =
(GetTimeZoneDataInternal)Delegate.CreateDelegate
(typeof(GetTimeZoneDataInternal),
t.GetType ().GetMethod (GetTimeZoneData,
BindingFlags.NonPublic | BindingFlags.Static |
BindingFlags.InvokeMethod));
long[] data = null;
string[] names = null;
var result = getTimeZoneData (2013, out data, out names);
Assert.IsTrue (result);
}
{/code}
The names variable contains [ NZDT, NZST ] while data contains [
6350090040, 6351601680, 4680, -360 ].
This is interesting as per the documentation of this method data[3]:
additional offset when daylight saving (in TimeSpan ticks)..
According to this function, in NZ we jump backwards into daylight
savings.
Sadly my experience with timezone calculations is limited, my C is
poor and with a weath of knowledge out here it is far to easy to ask.
Does anyone have a clue what is going on here?
Any help would be appreciated.
Thanks.
[1]
$ cat /etc/gentoo-release
Gentoo Base System release 2.2
$ date +%Z
NZDT
$ mono --version
Mono Runtime Engine version 3.2.3 (branch-master/a57f9ce Sun Oct 20
00:18:37 NZDT 2013)
Copyright (C) 2002-2013 Novell, Inc, Xamarin Inc and Contributors.
www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC:sgen
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] sgen optimizing
We have an application with a fairly common usage pattern. We send many messages in memory between a series of components (often with queues in the middle). In looking through sgen and defaults etc it would seem that by default there is a 4kb nursery. In this case we would have many of these small short lived messages getting promoted to the main heap. Is this a usage scenario where we might want to increase the size of the nursery to prevent the false promotions (aside from the messages we allocate very little else). Cheers, Greg -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sgen optimizing
sorry for type meant 4mb not 4kb (that would be a really small nursery!) On Mon, Oct 28, 2013 at 3:38 PM, Greg Young gregoryyou...@gmail.com wrote: We have an application with a fairly common usage pattern. We send many messages in memory between a series of components (often with queues in the middle). In looking through sgen and defaults etc it would seem that by default there is a 4kb nursery. In this case we would have many of these small short lived messages getting promoted to the main heap. Is this a usage scenario where we might want to increase the size of the nursery to prevent the false promotions (aside from the messages we allocate very little else). Cheers, Greg -- Le doute n'est pas une condition agréable, mais la certitude est absurde. -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] why does DateTime.Now.IsDaylightSavingTime() returns false when it should be true.
On 28.10.2013 07:35, Alistair Bush wrote:
I am trying to figure out why exactly running
DateTime.Now.IsDaylightSavingTIme() returns false.
I live in the Auckland/Pacific timezone and pretty much everywhere I
look it confirms that yes it is daylight saving time.
Unfortunately, I don't remember the details, but I'm pretty
sure that ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData
has a bug w/ respect to the Southern Hemisphere.
The code assumes that a year always begins outside a DST zone,
and this is obviously incorrect for the Southern Hemisphere.
To fix this, the local var is_daylight must be properly
initialized. Currently, it's always 0 at start, but it must
be initialized with 1 when January, 1st is inside a DST
zone.
Maybe this:
is_daylight = start.tm_isdst 0;
just before
/* For each day of the year, calculate the tm_gmtoff. */
for (day = 0; day 365; day++) {
Robert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sgen optimizing
Increasing the nursery size will reduce the amount of ephemeral garbage that gets promoted to the old generation. The downside of a larger nursery is the increased pause times for minor collections. Sgen has a separate nursery designed to reduce temporal garbage by making objects age in the nursery before promoting them. You can try it with MON_GC_PARAMS=minor=split. On Mon, Oct 28, 2013 at 9:40 AM, Greg Young gregoryyou...@gmail.com wrote: sorry for type meant 4mb not 4kb (that would be a really small nursery!) On Mon, Oct 28, 2013 at 3:38 PM, Greg Young gregoryyou...@gmail.comwrote: We have an application with a fairly common usage pattern. We send many messages in memory between a series of components (often with queues in the middle). In looking through sgen and defaults etc it would seem that by default there is a 4kb nursery. In this case we would have many of these small short lived messages getting promoted to the main heap. Is this a usage scenario where we might want to increase the size of the nursery to prevent the false promotions (aside from the messages we allocate very little else). Cheers, Greg -- Le doute n'est pas une condition agréable, mais la certitude est absurde. -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sgen optimizing
On 28/10/13 15:42, Rodrigo Kumpera wrote: The downside of a larger nursery is the increased pause times for minor collections. The concurrent-garbage-collector announced at the Mono 3.0 release would also be an alternative to avoid the pause times, right? If yes, is the concurrent-garbage-collector the default for multi-core archs? If not, why not? Thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sgen optimizing
On Mon, Oct 28, 2013 at 10:48 AM, Andrés G. Aragoneses kno...@gmail.comwrote: On 28/10/13 15:42, Rodrigo Kumpera wrote: The downside of a larger nursery is the increased pause times for minor collections. The concurrent-garbage-collector announced at the Mono 3.0 release would also be an alternative to avoid the pause times, right? The concurrent collector is only for major collections, it doesn't help pause times for minor collections. If yes, is the concurrent-garbage-collector the default for multi-core archs? If not, why not? The concurrent collection remains experimental and under development. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] why does DateTime.Now.IsDaylightSavingTime() returns false when it should be true.
Well that certainly sucks.
On Tue, Oct 29, 2013 at 3:03 AM, Robert Jordan robe...@gmx.net wrote:
On 28.10.2013 07:35, Alistair Bush wrote:
I am trying to figure out why exactly running
DateTime.Now.**IsDaylightSavingTIme() returns false.
I live in the Auckland/Pacific timezone and pretty much everywhere I
look it confirms that yes it is daylight saving time.
Unfortunately, I don't remember the details, but I'm pretty
sure that ves_icall_System_**CurrentSystemTimeZone_**GetTimeZoneData
has a bug w/ respect to the Southern Hemisphere.
The code assumes that a year always begins outside a DST zone,
and this is obviously incorrect for the Southern Hemisphere.
To fix this, the local var is_daylight must be properly
initialized. Currently, it's always 0 at start, but it must
be initialized with 1 when January, 1st is inside a DST
zone.
Maybe this:
is_daylight = start.tm_isdst 0;
just before
/* For each day of the year, calculate the tm_gmtoff. */
for (day = 0; day 365; day++) {
Robert
__**_
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.**com Mono-devel-list@lists.ximian.com
http://lists.ximian.com/**mailman/listinfo/mono-devel-**listhttp://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
