digitalmars.D.bugs - std.date again
- Carlos Santander (33/33) May 08 2006 Here it's again:
- Kyle Furlong (6/56) May 08 2006 You might want to use mango.locale.
- Carlos Santander (4/59) May 09 2006 I know there're other options, but that's no reason for Phobos to be wro...
- Dejan Lekic (8/8) May 09 2006 I am getting AssertError when running your example on both Linux and
- Carlos Santander (4/13) May 09 2006 Are you sure you didn't change it to "int main()" and forgot to add a re...
- Walter Bright (2/50) May 12 2006 So you're saying the linux results are correct?
- Carlos Santander (4/55) May 12 2006 No, I'm saying the UTC result on linux is the correct local result.
- Walter Bright (3/4) May 12 2006 It's hard for me to debug this, because it works in my timezone. Want to...
- Carlos Santander (41/47) May 15 2006 I'm completely confused about this whole thing, and I think the problem ...
- =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= (11/67) May 12 2006 It's GMT + 2 + Daylight saving Time here now:
Here it's again:
//------------------------
import std.date;
import std.stdio;
void main()
{
writefln("UTC :%s", toTimeString(getUTCtime()));
writefln("Local:%s", toTimeString(UTCtoLocalTime(getUTCtime())));
}
//------------------------
:::: gdc 0.17, Mac OS X 10.4.6
$ ./test
UTC :06:20:52 GMT+0500
Local:11:20:52 GMT+0500
$ date
Mon May 8 20:21:01 ECT 2006
:::: DMD 0.155, Windows XP SP 2
D:\>test
UTC :01:27:19 GMT+0000
Local:01:27:19 GMT+0000
D:\>time
La hora actual es: 20:27:32,08
:::: DMD 0.155, Mandrake Linux 10.1
$ ./test
UTC :20:34:23 GMT-0500
Local:15:34:23 GMT-0500
$ date
lun may 8 20:34:27 ECT 2006
Walter, at least take a look at UTC on Linux: that's the correct local time,
which most certainly gives a clue of where the solution might be.
In all my systems, the timezone is GMT -0500 aka Bogotá, Lima, Quito, aka ECT.
--
Carlos Santander Bernal
May 08 2006
Carlos Santander wrote:
Here it's again:
//------------------------
import std.date;
import std.stdio;
void main()
{
writefln("UTC :%s", toTimeString(getUTCtime()));
writefln("Local:%s", toTimeString(UTCtoLocalTime(getUTCtime())));
}
//------------------------
:::: gdc 0.17, Mac OS X 10.4.6
$ ./test
UTC :06:20:52 GMT+0500
Local:11:20:52 GMT+0500
$ date
Mon May 8 20:21:01 ECT 2006
:::: DMD 0.155, Windows XP SP 2
D:\>test
UTC :01:27:19 GMT+0000
Local:01:27:19 GMT+0000
D:\>time
La hora actual es: 20:27:32,08
:::: DMD 0.155, Mandrake Linux 10.1
$ ./test
UTC :20:34:23 GMT-0500
Local:15:34:23 GMT-0500
$ date
lun may 8 20:34:27 ECT 2006
Walter, at least take a look at UTC on Linux: that's the correct local
time, which most certainly gives a clue of where the solution might be.
In all my systems, the timezone is GMT -0500 aka Bogotá, Lima, Quito,
aka ECT.
You might want to use mango.locale.
http://dsource.org/projects/mango/browser/trunk/mango/locale?rev=883
--
Kyle Furlong // Physics Undergrad, UCSB
"D is going wherever the D community wants it to go." - Walter Bright
May 08 2006
Carlos Santander <csantander619 gmail.com> Kyle Furlong escribió:Carlos Santander wrote:I know there're other options, but that's no reason for Phobos to be wrong. -- Carlos Santander BernalHere it's again: //------------------------ import std.date; import std.stdio; void main() { writefln("UTC :%s", toTimeString(getUTCtime())); writefln("Local:%s", toTimeString(UTCtoLocalTime(getUTCtime()))); } //------------------------ :::: gdc 0.17, Mac OS X 10.4.6 $ ./test UTC :06:20:52 GMT+0500 Local:11:20:52 GMT+0500 $ date Mon May 8 20:21:01 ECT 2006 :::: DMD 0.155, Windows XP SP 2 D:\>test UTC :01:27:19 GMT+0000 Local:01:27:19 GMT+0000 D:\>time La hora actual es: 20:27:32,08 :::: DMD 0.155, Mandrake Linux 10.1 $ ./test UTC :20:34:23 GMT-0500 Local:15:34:23 GMT-0500 $ date lun may 8 20:34:27 ECT 2006 Walter, at least take a look at UTC on Linux: that's the correct local time, which most certainly gives a clue of where the solution might be. In all my systems, the timezone is GMT -0500 aka Bogotá, Lima, Quito, aka ECT.You might want to use mango.locale. http://dsource.org/projects/mango/browser/trunk/mango/locale?rev=883
May 09 2006
I am getting AssertError when running your example on both Linux and Windows: $ ./std_date_01.exe UTC :12:48:08 GMT+0200 Local:14:48:08 GMT+0200 Error: AssertError Failure std_date_01(8) DMD version: 0.156 compiled with: dmd std_date_01.d
May 09 2006
Dejan Lekic escribió:I am getting AssertError when running your example on both Linux and Windows: $ ./std_date_01.exe UTC :12:48:08 GMT+0200 Local:14:48:08 GMT+0200 Error: AssertError Failure std_date_01(8) DMD version: 0.156 compiled with: dmd std_date_01.dAre you sure you didn't change it to "int main()" and forgot to add a return? -- Carlos Santander Bernal
May 09 2006
Carlos Santander wrote:
Here it's again:
//------------------------
import std.date;
import std.stdio;
void main()
{
writefln("UTC :%s", toTimeString(getUTCtime()));
writefln("Local:%s", toTimeString(UTCtoLocalTime(getUTCtime())));
}
//------------------------
:::: gdc 0.17, Mac OS X 10.4.6
$ ./test
UTC :06:20:52 GMT+0500
Local:11:20:52 GMT+0500
$ date
Mon May 8 20:21:01 ECT 2006
:::: DMD 0.155, Windows XP SP 2
D:\>test
UTC :01:27:19 GMT+0000
Local:01:27:19 GMT+0000
D:\>time
La hora actual es: 20:27:32,08
:::: DMD 0.155, Mandrake Linux 10.1
$ ./test
UTC :20:34:23 GMT-0500
Local:15:34:23 GMT-0500
$ date
lun may 8 20:34:27 ECT 2006
Walter, at least take a look at UTC on Linux: that's the correct local
time, which most certainly gives a clue of where the solution might be.
In all my systems, the timezone is GMT -0500 aka Bogotá, Lima, Quito,
aka ECT.
So you're saying the linux results are correct?
May 12 2006
Walter Bright escribió:Carlos Santander wrote:No, I'm saying the UTC result on linux is the correct local result. -- Carlos Santander BernalHere it's again: //------------------------ import std.date; import std.stdio; void main() { writefln("UTC :%s", toTimeString(getUTCtime())); writefln("Local:%s", toTimeString(UTCtoLocalTime(getUTCtime()))); } //------------------------ :::: gdc 0.17, Mac OS X 10.4.6 $ ./test UTC :06:20:52 GMT+0500 Local:11:20:52 GMT+0500 $ date Mon May 8 20:21:01 ECT 2006 :::: DMD 0.155, Windows XP SP 2 D:\>test UTC :01:27:19 GMT+0000 Local:01:27:19 GMT+0000 D:\>time La hora actual es: 20:27:32,08 :::: DMD 0.155, Mandrake Linux 10.1 $ ./test UTC :20:34:23 GMT-0500 Local:15:34:23 GMT-0500 $ date lun may 8 20:34:27 ECT 2006 Walter, at least take a look at UTC on Linux: that's the correct local time, which most certainly gives a clue of where the solution might be. In all my systems, the timezone is GMT -0500 aka Bogotá, Lima, Quito, aka ECT.So you're saying the linux results are correct?
May 12 2006
Carlos Santander wrote:No, I'm saying the UTC result on linux is the correct local result.It's hard for me to debug this, because it works in my timezone. Want to give it a try in yours?
May 12 2006
Walter Bright escribió:Carlos Santander wrote:I'm completely confused about this whole thing, and I think the problem is documentation. -- On linux (DMD): If I do toUTCString(getUTCtime()) I correctly get: Mon, 15 May 2006 17:58:57 UTC But when I do toTimeString(getUTCtime()) I get: 12:58:57 GMT-0500 So I think toTimeString must be wrong, my logic being that I asked it to return the current time as UTC time. But what it returned was the time for my local timezone. However, it's never explicitly stated that it should behave that way. -- On mac (GDC): It's the same as linux, but the timezone seems to be doing the opposite: UTC :Mon, 15 May 2006 18:07:44 UTC Local:04:07:44 GMT+0500 So it performed an addition instead of a difference. -- On windows (DMD): toTimeString(getUTCtime()) returns: 18:13:14 GMT+0000 And toUTCString(getUTCtime()): Mon, 15 May 2006 18:13:14 UTC So, on windows, these are ok, I think. At least they behave as I expected them to. If I'm right with this, then toTimeString on linux is definitely wrong. Now, toTimeString(UTCtoLocalTime(getUTCtime())) also returns: 18:13:14 GMT+0000 So, unless toTimeString always prints UTC time (which I don't think it should), this is obviously wrong, and the problem has to be in the timezone conversion. Part of the solution might be here: http://www.digitalmars.com/drn-bin/wwwnews?D/20470, but if GetTimeZoneInformation() fails, what if instead you use GetLocalTime() to get the local time, and since getUTCtime() is ok, then you could use those two values to get the timezone (UTCtime - localtime). Does that make sense? -- Finally.... It's easy, in fact, for you to test it too: change your timezone to different parts of the world when debugging this and see what happens. It's really easy to do in both linux and windows. Sorry if that sounded harsh, but I think right now std.date doesn't work in a usable way outside your own timezone and maybe a couple more, and that is a shame for D, especially since these problems have been around for so long. -- Carlos Santander BernalNo, I'm saying the UTC result on linux is the correct local result.It's hard for me to debug this, because it works in my timezone. Want to give it a try in yours?
May 15 2006
Carlos Santander wrote:Walter Bright escribió:It's GMT + 2 + Daylight saving Time here now: $ ./test UTC :23:27:47 GMT+0300 Local:02:27:47 GMT+0300 $ date pe 12.5.2006 23:27:58 +0300 The date values have been this way (=wrong) as long as I remember. 'UTC' in D is the current local time and 'Local' is UTC + 2 * (Local - UTC). -- Jari-MattiCarlos Santander wrote:No, I'm saying the UTC result on linux is the correct local result.Here it's again: //------------------------ import std.date; import std.stdio; void main() { writefln("UTC :%s", toTimeString(getUTCtime())); writefln("Local:%s", toTimeString(UTCtoLocalTime(getUTCtime()))); } //------------------------ :::: gdc 0.17, Mac OS X 10.4.6 $ ./test UTC :06:20:52 GMT+0500 Local:11:20:52 GMT+0500 $ date Mon May 8 20:21:01 ECT 2006 :::: DMD 0.155, Windows XP SP 2 D:\>test UTC :01:27:19 GMT+0000 Local:01:27:19 GMT+0000 D:\>time La hora actual es: 20:27:32,08 :::: DMD 0.155, Mandrake Linux 10.1 $ ./test UTC :20:34:23 GMT-0500 Local:15:34:23 GMT-0500 $ date lun may 8 20:34:27 ECT 2006 Walter, at least take a look at UTC on Linux: that's the correct local time, which most certainly gives a clue of where the solution might be. In all my systems, the timezone is GMT -0500 aka Bogotá, Lima, Quito, aka ECT.So you're saying the linux results are correct?
May 12 2006