Testing generated/osx/debug/unittest/std/datetime
core.time.TimeException at std/datetime.d(28734): File
/usr/share/zoneinfo//right/A
merica/Los_Angeles does not exist.
----------------
5   datetime                            0x0016bbe8 bool
std.exception.enforce!(b
ool).enforce(bool, lazy object.Throwable) + 40
6   datetime                            0x0015506d
immutable(std.datetime.PosixT
imeZone) std.datetime.PosixTimeZone.getTimeZone(immutable(char)[],
immutable(cha
r)[]) + 237
7   datetime                            0x0015700a void
std.datetime.PosixTimeZo
ne.__unittest338() + 1914
8   datetime                            0x00002768 void
std.datetime.__modtest()
 + 1496
9   datetime                            0x001b089d extern (C) bool
core.runtime.
runModuleUnitTests().int __foreachbody238(ref object.ModuleInfo*) + 45
10  datetime                            0x001abf63 int
object.ModuleInfo.opApply
(scope int delegate(ref object.ModuleInfo*)) + 79
11  datetime                            0x001b078e runModuleUnitTests + 134
12  datetime                            0x001b99ee extern (C) int
rt.dmain2.main
(int, char**).void runAll() + 38
13  datetime                            0x001b9942 extern (C) int
rt.dmain2.main
(int, char**).void tryExec(scope void delegate()) + 38
14  datetime                            0x001b98d3 main + 179
15  datetime                            0x00002169 start + 53
make[2]: *** [generated/osx/debug/unittest/std/datetime] Error 1
make[1]: *** [unittest] Error 2
make: *** [unittest] Error 2

On Saturday 15 January 2011 11:37:14 Walter Bright wrote:
> Testing generated/osx/debug/unittest/std/datetime
> core.time.TimeException at std/datetime.d(28734): File
> /usr/share/zoneinfo//right/A
> merica/Los_Angeles does not exist.
> ----------------
> 5   datetime                            0x0016bbe8 bool
> std.exception.enforce!(b
> ool).enforce(bool, lazy object.Throwable) + 40
> 6   datetime                            0x0015506d
> immutable(std.datetime.PosixT
> imeZone) std.datetime.PosixTimeZone.getTimeZone(immutable(char)[],
> immutable(cha
> r)[]) + 237
> 7   datetime                            0x0015700a void
> std.datetime.PosixTimeZo
> ne.__unittest338() + 1914
> 8   datetime                            0x00002768 void
> std.datetime.__modtest()
>  + 1496
> 9   datetime                            0x001b089d extern (C) bool
> core.runtime.
> runModuleUnitTests().int __foreachbody238(ref object.ModuleInfo*) + 45
> 10  datetime                            0x001abf63 int
> object.ModuleInfo.opApply
> (scope int delegate(ref object.ModuleInfo*)) + 79
> 11  datetime                            0x001b078e runModuleUnitTests + 134
> 12  datetime                            0x001b99ee extern (C) int
> rt.dmain2.main
> (int, char**).void runAll() + 38
> 13  datetime                            0x001b9942 extern (C) int
> rt.dmain2.main
> (int, char**).void tryExec(scope void delegate()) + 38
> 14  datetime                            0x001b98d3 main + 179
> 15  datetime                            0x00002169 start + 53
> make[2]: *** [generated/osx/debug/unittest/std/datetime] Error 1
> make[1]: *** [unittest] Error 2
> make: *** [unittest] Error 2

So, either OSX does _not_ have the time zone files in /usr/share/zoneinfo as I was told that they did, or they didn't actually put them all on the system. Can you verify whether the time zone files are located in /usr/share/zoneinfo or not? The test in question is easily disabled on OSX, so that's not a big deal, but it _is_  big deal if the time zone files aren't where they are on Liunx.

- Jonathan M Davis

The OSX file is

/usr/share/zoneinfo/America/Los_Angeles

not

/usr/share/zoneinfo//right/America/Los_Angeles

Jonathan M Davis wrote:
> On Saturday 15 January 2011 11:37:14 Walter Bright wrote:
> 
>> Testing generated/osx/debug/unittest/std/datetime
>> core.time.TimeException at std/datetime.d(28734): File
>> /usr/share/zoneinfo//right/A
>> merica/Los_Angeles does not exist.
>> ----------------
>> 5   datetime                            0x0016bbe8 bool
>> std.exception.enforce!(b
>> ool).enforce(bool, lazy object.Throwable) + 40
>> 6   datetime                            0x0015506d
>> immutable(std.datetime.PosixT
>> imeZone) std.datetime.PosixTimeZone.getTimeZone(immutable(char)[],
>> immutable(cha
>> r)[]) + 237
>> 7   datetime                            0x0015700a void
>> std.datetime.PosixTimeZo
>> ne.__unittest338() + 1914
>> 8   datetime                            0x00002768 void
>> std.datetime.__modtest()
>>  + 1496
>> 9   datetime                            0x001b089d extern (C) bool
>> core.runtime.
>> runModuleUnitTests().int __foreachbody238(ref object.ModuleInfo*) + 45
>> 10  datetime                            0x001abf63 int
>> object.ModuleInfo.opApply
>> (scope int delegate(ref object.ModuleInfo*)) + 79
>> 11  datetime                            0x001b078e runModuleUnitTests + 134
>> 12  datetime                            0x001b99ee extern (C) int
>> rt.dmain2.main
>> (int, char**).void runAll() + 38
>> 13  datetime                            0x001b9942 extern (C) int
>> rt.dmain2.main
>> (int, char**).void tryExec(scope void delegate()) + 38
>> 14  datetime                            0x001b98d3 main + 179
>> 15  datetime                            0x00002169 start + 53
>> make[2]: *** [generated/osx/debug/unittest/std/datetime] Error 1
>> make[1]: *** [unittest] Error 2
>> make: *** [unittest] Error 2
>> 
>
> So, either OSX does _not_ have the time zone files in /usr/share/zoneinfo as I was told that they did, or they didn't actually put them all on the system. Can you verify whether the time zone files are located in /usr/share/zoneinfo or not? The test in question is easily disabled on OSX, so that's not a big deal, but it _is_  big deal if the time zone files aren't where they are on Liunx.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
>
> 

On Saturday 15 January 2011 17:52:10 Walter Bright wrote:
> The OSX file is
> 
> /usr/share/zoneinfo/America/Los_Angeles
> 
> not
> 
> /usr/share/zoneinfo//right/America/Los_Angeles

They both exist on Linux. The one in right/ has leap seconds whereas the other one doesn't. The test is using /usr/share/zoneinfo/right/America/Los_Angeles to test the leap second functionality.

So, you're saying that the folks at Apple _did_ put the time zone files in /usr/share/zoneinfo, but that they _didn't_ use all of the standard time zone files and left out the directory /usr/share/zoneinfo/right? If that's the case, then I'll just make that test Linux-only.

It's already a bit weird with Linux, since glibc ignores the leap seconds if you use the the right/ files. I made it so that if you selected a time zone file with leap seconds in it, then the leap seconds were used. But regardless, the OS won't use them. So, if they're not present on OSX, it's probably because they'd never get used anyway.

- Jonathan M Davis

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110115/ccff9456/attachment.html>

On Saturday 15 January 2011 18:19:24 Walter Bright wrote:
>  Jonathan M Davis wrote:
> On Saturday 15 January 2011 17:52:10 Walter Bright wrote:
> 
> The OSX file is
> 
> /usr/share/zoneinfo/America/Los_Angeles
> 
> not
> 
> /usr/share/zoneinfo//right/America/Los_Angeles
> 
> 
> They both exist on Linux. The one in right/ has leap seconds whereas the other one doesn't. The test is using /usr/share/zoneinfo/right/America/Los_Angeles to test the leap second functionality.
> 
> So, you're saying that the folks at Apple _did_ put the time zone files in /usr/share/zoneinfo, but that they _didn't_ use all of the standard time zone files and left out the directory /usr/share/zoneinfo/right? If that's the case, then I'll just make that test Linux-only.
> 
> 
>  I'm not saying anything other than there is no subdirectory on OSX called
> /usr/share/zoneinfo/right (or //right, what's with the double slash?)

Well, that's what I wanted to know. The fact that it's not there means that they didn't put all of the standard time zone files on Mac OSX, since the right/ files are part of the standard time zone files (which is funny considering that, as far as I know, only Posix systems use the standard time zone files and the Posix standard explicitly says to ignore leap seconds, but the standard for the time zone files has nothing to do with Posix).

The double slash just means that there's a bug somewhere in std.datetime that slaps on a slash when it doesn't need to. It works either way since the extra slash is ignored by the OS, so it's not a big deal, but it's not supposed to be there.

I'll make the leap-seconds test Linux-only when I do a check-in later this evening, unless you need it right away, at which point I can do it now (it's just that that's a bit more of a pain for me, since I'm in the middle of some other changes and svn's branching capabilities suck).

- Jonathan M Davis

Jonathan M Davis wrote:
> I'll make the leap-seconds test Linux-only when I do a check-in later this evening, unless you need it right away, at which point I can do it now (it's just that that's a bit more of a pain for me, since I'm in the middle of some other changes and svn's branching capabilities suck).
>
> 

Thanks. Please fix the path thing, too. Also, would it be better instead of versioning the code, to test to see if the 'right' directory exists, and make a decision on that?

On Saturday 15 January 2011 19:52:32 Walter Bright wrote:
> Jonathan M Davis wrote:
> > I'll make the leap-seconds test Linux-only when I do a check-in later this evening, unless you need it right away, at which point I can do it now (it's just that that's a bit more of a pain for me, since I'm in the middle of some other changes and svn's branching capabilities suck).
> 
> Thanks. Please fix the path thing, too. Also, would it be better instead of versioning the code, to test to see if the 'right' directory exists, and make a decision on that?

Good point. I'll do that instead.

- Jonathan M Davis

Don't know if it helps but I found this:

/etc/localtime                  			local time zone file
/usr/share/zoneinfo             			time zone directory
/usr/share/zoneinfo/posixrules  	rules for POSIX-style TZ's
/usr/share/zoneinfo/GMT         		for UTC leap seconds

If the file /usr/share/zoneinfo/GMT does not exist, UTC leap seconds are loaded from /usr/share/zoneinfo/posixrules.

http://developer.apple.com/library/mac/#documentation/darwin/reference/manpages/man3/tzsetwall.3.html


/Jacob Carlborg

On 16 jan 2011, at 03:00, Jonathan M Davis wrote:

> On Saturday 15 January 2011 17:52:10 Walter Bright wrote:
>> The OSX file is
>> 
>> /usr/share/zoneinfo/America/Los_Angeles
>> 
>> not
>> 
>> /usr/share/zoneinfo//right/America/Los_Angeles
> 
> They both exist on Linux. The one in right/ has leap seconds whereas the other one doesn't. The test is using /usr/share/zoneinfo/right/America/Los_Angeles to test the leap second functionality.
> 
> So, you're saying that the folks at Apple _did_ put the time zone files in /usr/share/zoneinfo, but that they _didn't_ use all of the standard time zone files and left out the directory /usr/share/zoneinfo/right? If that's the case, then I'll just make that test Linux-only.
> 
> It's already a bit weird with Linux, since glibc ignores the leap seconds if you use the the right/ files. I made it so that if you selected a time zone file with leap seconds in it, then the leap seconds were used. But regardless, the OS won't use them. So, if they're not present on OSX, it's probably because they'd never get used anyway.
> 
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

On Sunday 16 January 2011 03:50:08 Jacob Carlborg wrote:
> Don't know if it helps but I found this:
> 
> /etc/localtime                  			local time zone file
> /usr/share/zoneinfo             			time zone directory
> /usr/share/zoneinfo/posixrules  	rules for POSIX-style TZ's
> /usr/share/zoneinfo/GMT         		for UTC leap seconds
> 
> If the file /usr/share/zoneinfo/GMT does not exist, UTC leap seconds are loaded from /usr/share/zoneinfo/posixrules.
> 
> http://developer.apple.com/library/mac/#documentation/darwin/reference/manp ages/man3/tzsetwall.3.html

Welll, the leap seconds are universal. Those won't vary from time zone to time zone. The time zone files themselves may or may not have them, so if a program reading them in wants to actually use leap seconds, and all it's going by is the time zone files, then whether or not leap seconds are used would depend on whether they're in the time zone file or not. However, it's quite possible that posixrules and GMT contain leap seconds and a program (or the OS) could take the leap seconds from there and apply them to any time zone which doesn't have leap seconds in its time zone file.

Regardless, the posix standard says to ignore leap seconds, so that's what glibc and Linux does. However, that's not to say that the Mac isn't doing something different.

From what I recall, all of the time zones in right/ had leap seconds in them and none of the others did, but it's quite possible that posixrules and GMT do, and I forgot. So, the OSX may just load them from there. It certainly sounds like it does in that documentation.

Regardless, I'm not terribly interested in leap seconds (I think that they should be abolished along with DST) - particularly since the Posix standard disallows them - but since they _are_ in certain time zone files, and some crazy programmer may want to use them, or some poor programmer may be forced to use them, it seemed like I might as well make it so that std.datetime.PosixTimeZone applied leap seconds to time zones whose time zone file contained leap seconds. So, I did.

However, with the current design of PosixTimeZone, if a programmer wants to use leap seconds, they need to pick a time zone whose file includes leap seconds. There's no way to grab the time zone rules from one file and the leap seconds from another. So, you couldn't use leap seconds on a Mac unless you brought along your own time zone files. But since you can't do it on _Windows_ without bringing along your own time zone files (since, as far as I can tell, Windows has not support for leap seconds, and WindowsTimeZone certainly doesn't), I don't see that as being a big deal.

Regardless, thanks for the info. If nothing else, it does show that Mac OS X is doing its own thing with regards to leap seconds. It does make me wonder though if they try and use them normally (by the system clock), or if it's just something that _can_ be used if you use the right functions. As I understand it, the Posix standard requires that leap seconds be ignored, so if the OSX system clock uses it, then that would be breaking the standard.

- Jonathan M Davis