Re: API Change Proposal: Change UDTS_WINDOWS_DATE_TIME to UDTS_DOTNET_DATE_TIME

Agreed on #1, no reason to keep the old one and the current name is
wrong.

As for #2, as you prefer.

tex


Eric Mader wrote:
> 
> To add to George's answer for #1, the name UDTS_WINDOWS_DATE_TIME is
> just plain wrong. Since this API is brand new, there doesn't seem to be
> much reason to keep the old name around. I think that it would just
> cause confusion.
> 
> To answer #2, it seems to me that the .NET platform is key to everything
> that Micorsoft is doing for the next few years, and is not likely to go
> away anytime soon. If they *do* change the name, we can always add an
> alias with the new name.
> 
> Regards,
> Eric
> 
> George Rhoten wrote:
> > To answer #1, the proposal states that it's to change the enum.  Since
> > this is still draft API, there is no reason to keep the old constant
> > around.  This is not stable API that is being proposed for change.
> >
> > George Rhoten
> > IBM Globalization Center of Competency/ICU  San José, CA, USA
> >
> >
> >
> > Tex Texin <[email protected]>
> > Sent by: [email protected]
> > 01/23/2005 03:07 AM
> >
> > To
> > Eric Mader <[email protected]>
> > cc
> > [email protected]
> > Subject
> > Re: API Change Proposal: Change UDTS_WINDOWS_DATE_TIME to
> > UDTS_NOTNET_DATE_TIME
> >
> >
> >
> >
> >
> >
> > 1) Is the proposal to change the name, or to add the new name, while
> > keeping the old name for compatibility, and consider the old one
> > deprecated?
> >
> > 2) Is it a good idea to use names so closely tied to a product?
> > These products change names and get reinvented every couple of years,
> > although the data types are much more stable. (com, dcom, ole, ocx...)
> >
> > Would it be better to use a name that reflected the 64 bit nature and
> > the offset (1/1/1/) of the datatype and then separately document this
> > data type is used by dotnet?
> >
> > Then when the product name changes, the API doesn't.
> > The name can then also be shared if the data type is used by other
> > non-windows software, instead of adding new constant names for the same
> > thing.
> >
> > tex
> >
> > Eric Mader wrote:
> >
> >>Please send comments by 01/28/2005.
> >>
> >>The universal time scale API in utmscale.h and
> >>com.ibm.icu.util.UniversalTimeScale.java talks about a time scale called
> >>"Windows DateTime." There isn't any such data type of time scale in the
> >>Windows 32-bit API. What was meant was .NET's System.DateTime structure.
> >>
> >>This proposal is to change the names of the constants that reference
> >>this time scale to correctly reflect it's origin:
> >>
> >>ICU4C: UDTS_WINDOWS_DATE_TIME => UDTS_DOTNET_DATE_TIME
> >>ICU4J: WINDOWS_DATE_TIME => DOTNET_DATE_TIME.
> >>
> >>The actual data for this time scale (a 64-bit integer of ticks since
> >>Midnight January 01, 0001) is correct; we're only changing the name to
> >>more correctly reflect the source of the time scale.
> >>
> >>Regards,
> >>Eric Mader
> >>IBM GCoC - San José
> >>5600 Cottle Road  M/S 50-2/B11
> >>San Jose, CA 95193
> >>
> >>_______________________________________________
> >>icu mailing list
> >>[email protected]
> >>http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
> >
> >
> 
> _______________________________________________
> icu mailing list
> [email protected]
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:[email protected]
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------