Bug 37082

GemStone/S 64 Bit

3.4.2, 3.4.1, 3.4, 3.3.7, 3.3.6, 3.3.5, 3.3.4, 3.3.3, 3.3.1, 3.3, 3.2.16, 3.2.15, 3.2.14, 3.2.13, 3.2.12, 3.2.11, 3.2.10, 3.2.9, 3.2.8.1, 3.2.8, 3.2.7, 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2, 3.1.0.6, 3.1.0.5, 3.1.0.4, 3.1.0.3, 3.1.0.2, 3.1.0.1, 3.1, 3.0.1, 3.0, 2.4.8, 2.4.7, 2.4.6, 2.4.5.1, 2.4.5, 2.4.4.8, 2.4.4.7, 2.4.4.6, 2.4.4.5, 2.4.4.4, 2.4.4.3, 2.4.4, 2.4.3, 2.4.2, 2.4.1, 2.4, 2.3.1.6, 2.3.1, 2.3, 2.2.5.4, 2.2.5.3, 2.2.5.2, 2.2.5.1, 2.2.5, 2.2.x, 2.2, 2.1.4, 2.1.x, 2.1, 2.0.5, 2.0.4, 2.0.3, 2.0.x, 1.2.4, 1.2.x, 1.1.x, 1.x

All

DateTime creation on boundaries of Daylight Savings Time

Creation of local DateTimes at the start and end of DST are problematic.

Between the start date and time of DST and one hour later, there is no local time.  Attempts to create a local DateTime in this non-existent range do not fail, they return the DateTime one hour earlier.

Between the end date and time of DST and one hour earlier, the local Time is ambiguous; there are two distinct DateTimes that are correct representations of the local time.  The current creation mechanism returns the DateTime of the later of the two. Consequentially, there are certain GMT DateTimes (the earlier of the two for an ambiguous local time) that it is not possible to create using the DateTime local time creation methods

Workaround

Use the DateTime gmt creation methods to avoid the inherent ambiguity of the local time at the DST boundaries.


Last updated: 2/11/16