Time/Date formatting malfunctioning in Tokyo timezone
JLangseth1@aol.com Wednesday, October 16, 1996 My app is a dialog based MFC (4.2) project currently running on NT Server 4.0. I store a UTC for each record the user creates. When displaying the information I use CTime::Format to create a displayable image of the date and time (including the timezone with %Z). When I set the timezone in the control panel to Tokyo time (my customer is Japanese) Format somehow defaults to PDT (Pacific Daylight Time). Is this a known bug or am I doing something wrong? Is this routine only supported on a Japanese version of NT? I set the timezone to China and Australia and the string was formatted correctly. I understand that CTime::Format uses "strftime()" which is the likely source of the problem. I have UNICODE defined so that the wide character versions of system calls are being used. Thank you. Environment: MSVC/VC++ 4.2 NT 4.0
Simon Salter -- Simon@chersoft.co.uk Tuesday, October 22, 1996 CTime is a little bit limited. A quick delve into the source will show you that it is really just a thin wrapper for a time_t (aka long) and the C runtimes mktime() et al. This means that in the NT environment it really does not know very much about what is going on. In fact given the support that NT has for time zones and locales IMHO it falls well short of the mark. You might consider using the API calls ::GetDateFormat() and ::GetTimeFormat(). They have several advantages which include using a specified time zone and locale. It is a little bit of work to get all the bits together. You need to build a SYSTEMTIME structure which means you need the UTC value of the date/time you are dealing with. These can be extracted from a valid CTime. Herein lies a problem with CTime which I do not really understand; there seems to be no way to explicitly create a CTime directly from UTC values. The constructors always assume that the time values (hms etc.) are in the local time zone and make conversions appropriately. Internally a time_t is a representation of a UTC value. This then apparently leaves two options: a) You can create a time_t manually and then build a CTime from that. Maybe copy some of the mktime() source to do this. Obviously this requires implicit knowledge of what a time_t is which breaks the encapsulation of CTime. b) You can dump CTime and roll your own. At the same time extending the range and precision of the class and so on... This seems to be where I am headed although I suspect that a good time class implementation is not trivial. Simon ---------- From: JLangseth1@aol.com[SMTP:JLangseth1@aol.com] Sent: 17 October 1996 06:37 To: mfc-l@netcom.com Subject: Time/Date formatting malfunctioning in Tokyo timezone My app is a dialog based MFC (4.2) project currently running on NT Server 4.0. I store a UTC for each record the user creates. When displaying the information I use CTime::Format to create a displayable image of the date and time (including the timezone with %Z). When I set the timezone in the control panel to Tokyo time (my customer is Japanese) Format somehow defaults to PDT (Pacific Daylight Time). Is this a known bug or am I doing something wrong? Is this routine only supported on a Japanese version of NT? I set the timezone to China and Australia and the string was formatted correctly. I understand that CTime::Format uses "strftime()" which is the likely source of the problem. I have UNICODE defined so that the wide character versions of system calls are being used. Thank you. Environment: MSVC/VC++ 4.2 NT 4.0
pjn -- pjn@indigo.ie Thursday, October 24, 1996 On Tue, 22 Oct 1996 17:44:59 +0100, you wrote: >CTime is a little bit limited. A quick delve into the source will show=20 >you that it is really just a thin wrapper for a time_t (aka long) and=20 >the C runtimes mktime() et al. This means that in the NT environment=20 >it really does not know very much about what is going on. In fact=20 >given the support that NT has for time zones and locales IMHO it falls=20 >well short of the mark. > >You might consider using the API calls ::GetDateFormat() and=20 >::GetTimeFormat(). They have several advantages which include using a=20 >specified time zone and locale. It is a little bit of work to get all=20 >the bits together. You need to build a SYSTEMTIME structure which=20 >means you need the UTC value of the date/time you are dealing with.=20 >These can be extracted from a valid CTime. Herein lies a problem with=20 >CTime which I do not really understand; there seems to be no way to=20 >explicitly create a CTime directly from UTC values. The constructors=20 >always assume that the time values (hms etc.) are in the local time=20 >zone and make conversions appropriately. Internally a time_t is a=20 >representation of a UTC value. This then apparently leaves two=20 >options: >a) You can create a time_t manually and then build a CTime from that.=20 >Maybe copy some of the mktime() source to do this. Obviously this=20 >requires implicit knowledge of what a time_t is which breaks the=20 >encapsulation of CTime. >b) You can dump CTime and roll your own. At the same time extending=20 >the range and precision of the class and so on... This seems to be=20 >where I am headed although I suspect that a good time class=20 >implementation is not trivial. > >Simon > >---------- >From: JLangseth1@aol.com[SMTP:JLangseth1@aol.com] >Sent: 17 October 1996 06:37 >To: mfc-l@netcom.com >Subject: Time/Date formatting malfunctioning in Tokyo timezone > >My app is a dialog based MFC (4.2) project currently running on NT=20 >Server >4.0. > >I store a UTC for each record the user creates. When displaying the >information I use CTime::Format to create a displayable image of the=20 >date and >time (including the timezone with %Z). > >When I set the timezone in the control panel to Tokyo time (my=20 >customer is >Japanese) Format somehow defaults to PDT (Pacific Daylight Time). Is=20 >this a >known bug or am I doing something wrong? Is this routine only=20 >supported on a >Japanese version of NT? I set the timezone to China and Australia and=20 >the >string was formatted correctly. > >I understand that CTime::Format uses "strftime()" which is the likely=20 >source >of the problem. I have UNICODE defined so that the wide character=20 >versions >of system calls are being used. > >Thank you. > >Environment: MSVC/VC++ 4.2 NT 4.0 > > Having utterly given up on CTime, I decided to roll my own and I have implemented a complete replacement for it and a number of other date time classes. For those interested this package "DTime" is available at http://indigo.ie/~pjn/dtime.html [Moderator's note: This package is shareware and costs US$40. This kind of information should always be supplied when advertising your own product as a solution in this forum.] ''' =20 @ @ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= ooO-(_)-Ooo=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | PJ Naughter | | | | Software Developer Email: pjn@indigo.ie | | Softech Telecom Tel: +353-1-2958384 | | Fax: +353-1-2956290 | | Author of DTime - A Collection URL: http://indigo.ie/~pjn | | of Date & Time classes for MFC | | | | Addr: 7 Woodford, Brewery Road, Stillorgan, | | Blackrock, Co. Dublin, Republic of Ireland | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
| Вернуться в корень Архива |