You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/core/extensions/globalization.md
+17-39Lines changed: 17 additions & 39 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -45,9 +45,7 @@ The use of Unicode ensures that the same code units always map to the same chara
45
45
Even if you are developing an app that targets a single culture or region, you should use resource files to store strings and other resources that are displayed in the user interface. You should never add them directly to your code. Using resource files has a number of advantages:
46
46
47
47
- All the strings are in a single location. You don't have to search throughout your source code to identify strings to modify for a specific language or culture.
48
-
49
-
- There is no need to duplicate strings. Developers who don't use resource files often define the same string in multiple source code files. This duplication increases the probability that one or more instances will be overlooked when a string is modified.
50
-
48
+
- There's no need to duplicate strings. Developers who don't use resource files often define the same string in multiple source code files. This duplication increases the probability that one or more instances will be overlooked when a string is modified.
51
49
- You can include non-string resources, such as images or binary data, in the resource file instead of storing them in a separate standalone file, so they can be retrieved easily.
52
50
53
51
Using resource files has particular advantages if you are creating a localized app. When you deploy resources in satellite assemblies, the common language runtime automatically selects a culture-appropriate resource based on the user's current UI culture as defined by the <xref:System.Globalization.CultureInfo.CurrentUICulture%2A?displayProperty=nameWithType> property. As long as you provide an appropriate culture-specific resource and correctly instantiate a <xref:System.Resources.ResourceManager> object or use a strongly typed resource class, the runtime handles the details of retrieving the appropriate resources.
@@ -155,9 +153,7 @@ You should never persist date and time data in a format that can vary by culture
155
153
You can avoid this problem in any of three ways:
156
154
157
155
- Serialize the date and time in binary format rather than as a string.
158
-
159
156
- Save and parse the string representation of the date and time by using a custom format string that is the same regardless of the user's culture.
160
-
161
157
- Save the string by using the formatting conventions of the invariant culture.
162
158
163
159
The following example illustrates the last approach. It uses the formatting conventions of the invariant culture returned by the static <xref:System.Globalization.CultureInfo.InvariantCulture%2A?displayProperty=nameWithType> property.
@@ -169,7 +165,11 @@ The following example illustrates the last approach. It uses the formatting conv
169
165
170
166
A date and time value can have multiple interpretations, ranging from a general time ("The stores open on January 2, 2013, at 9:00 A.M.") to a specific moment in time ("Date of birth: January 2, 2013 6:32:00 A.M."). When a time value represents a specific moment in time and you restore it from a serialized value, you should ensure that it represents the same moment in time regardless of the user's geographical location or time zone.
171
167
172
-
The following example illustrates this problem. It saves a single local date and time value as a string in three [standard formats](../../standard/base-types/standard-date-and-time-format-strings.md) ("G" for general date long time, "s" for sortable date/time, and "o" for round-trip date/time) as well as in binary format.
168
+
The following example illustrates this problem. It saves a single local date and time value as a string in three [standard formats](../../standard/base-types/standard-date-and-time-format-strings.md):
'2013-03-30T18:00:00.0000000-07:00' --> 3/30/2013 6:00:00 PM Local
183
-
184
-
3/30/2013 6:00:00 PM Local
185
183
```
186
184
187
185
However, if you restore the data on a system in a different time zone, only the date and time value that was formatted with the "o" (round-trip) standard format string preserves time zone information and therefore represents the same instant in time. Here's the output when the date and time data is restored on a system in the Romance Standard Time zone:
'2023-03-30T18:00:00.0000000-07:00' --> 3/31/2023 3:00:00 AM Local
195
191
```
196
192
197
193
To accurately reflect a date and time value that represents a single moment of time regardless of the time zone of the system on which the data is deserialized, you can do any of the following:
198
194
199
195
- Save the value as a string by using the "o" (round-trip) standard format string. Then deserialize it on the target system.
200
-
201
196
- Convert it to UTC and save it as a string by using the "r" (RFC1123) standard format string. Then deserialize it on the target system and convert it to local time.
202
-
203
197
- Convert it to UTC and save it as a string by using the "u" (universal sortable) standard format string. Then deserialize it on the target system and convert it to local time.
204
198
205
-
- Convert it to UTC and save it in binary format. Then deserialize it on the target system and convert it to local time.
@@ -212,11 +204,9 @@ The following example illustrates each technique.
212
204
When the data is serialized on a system in the Pacific Standard Time zone and deserialized on a system in the Romance Standard Time zone, the example displays the following output:
213
205
214
206
```console
215
-
'2013-03-30T18:00:00.0000000-07:00' --> 3/31/2013 3:00:00 AM Local
216
-
'Sun, 31 Mar 2013 01:00:00 GMT' --> 3/31/2013 3:00:00 AM Local
217
-
'2013-03-31 01:00:00Z' --> 3/31/2013 3:00:00 AM Local
218
-
219
-
3/31/2013 3:00:00 AM Local
207
+
'2023-03-30T18:00:00.0000000-07:00' --> 3/31/2023 3:00:00 AM Local
208
+
'Sun, 31 Mar 2023 01:00:00 GMT' --> 3/31/2023 3:00:00 AM Local
209
+
'2023-03-31 01:00:00Z' --> 3/31/2023 3:00:00 AM Local
220
210
```
221
211
222
212
For more information, see [Convert times between time zones](../../standard/datetime/converting-between-time-zones.md).
@@ -233,9 +223,7 @@ For example, the transition from Pacific Standard Time to Pacific Daylight Time
233
223
To ensure that an arithmetic operation on date and time values produces accurate results, follow these steps:
234
224
235
225
1. Convert the time in the source time zone to UTC.
236
-
237
226
2. Perform the arithmetic operation.
238
-
239
227
3. If the result is a date and time value, convert it from UTC to the time in the source time zone.
240
228
241
229
The following example is similar to the previous example, except that it follows these three steps to correctly add 48 hours to March 9, 2013 at 10:30 A.M.
@@ -268,13 +256,11 @@ The handling of numbers depends on whether they are displayed in the user interf
268
256
269
257
### Display numeric values
270
258
271
-
Typically, when numbers are displayed in the user interface, you should use the formatting conventions of the user's culture, which is defined by the <xref:System.Globalization.CultureInfo.CurrentCulture%2A?displayProperty=nameWithType> property and by the <xref:System.Globalization.NumberFormatInfo> object returned by the `CultureInfo.CurrentCulture.NumberFormat` property. The formatting conventions of the current culture are automatically used when you format a date by using any of the following methods:
272
-
273
-
- The parameterless `ToString` method of any numeric type
259
+
Typically, when numbers are displayed in the user interface, you should use the formatting conventions of the user's culture, which is defined by the <xref:System.Globalization.CultureInfo.CurrentCulture%2A?displayProperty=nameWithType> property and by the <xref:System.Globalization.NumberFormatInfo> object returned by the `CultureInfo.CurrentCulture.NumberFormat` property. The formatting conventions of the current culture are automatically used when you format a date in the following ways:
274
260
275
-
-The `ToString(String)` method of any numeric type, which includes a format string as an argument
276
-
277
-
-The[composite formatting](../../standard/base-types/composite-formatting.md)feature, when it is used with numeric values
261
+
-Using the parameterless `ToString` method of any numeric type.
262
+
- Using the `ToString(String)` method of any numeric type, which includes a format string as an argument.
263
+
-Using[composite formatting](../../standard/base-types/composite-formatting.md) with numeric values.
278
264
279
265
The following example displays the average temperature per month in Paris, France. It first sets the current culture to French (France) before displaying the data, and then sets it to English (United States). In each case, the month names and temperatures are displayed in the format that is appropriate for that culture. Note that the two cultures use different decimal separators in the temperature value. Also note that the example uses the "MMMM" custom date and time format string to display the full month name, and that it allocates the appropriate amount of space for the month name in the result string by determining the length of the longest month name in the <xref:System.Globalization.DateTimeFormatInfo.MonthNames%2A?displayProperty=nameWithType> array.
280
266
@@ -291,17 +277,9 @@ You should never persist numeric data in a culture-specific format. This is a co
291
277
To avoid this problem, you can use one of these techniques:
292
278
293
279
- Save and parse the string representation of the number by using a custom format string that is the same regardless of the user's culture.
294
-
295
280
- Save the number as a string by using the formatting conventions of the invariant culture, which is returned by the <xref:System.Globalization.CultureInfo.InvariantCulture%2A?displayProperty=nameWithType> property.
296
281
297
-
- Serialize the number in binary instead of string format.
298
-
299
-
The following example illustrates the last approach. It serializes the array of <xref:System.Double> values, and then deserializes and displays them by using the formatting conventions of the English (United States) and French (France) cultures.
Serializing currency values is a special case. Because a currency value depends on the unit of currency in which it is expressed; it makes little sense to treat it as an independent numeric value. However, if you save a currency value as a formatted string that includes a currency symbol, it cannot be deserialized on a system whose default culture uses a different currency symbol, as the following example shows.
282
+
Serializing currency values is a special case. Because a currency value depends on the unit of currency in which it's expressed, it makes little sense to treat it as an independent numeric value. However, if you save a currency value as a formatted string that includes a currency symbol, it cannot be deserialized on a system whose default culture uses a different currency symbol, as the following example shows.
0 commit comments