How does CTime actually "apply" DST?

Question

4.00/5 (1 vote)

See more:

VS2005

According to MSDN, if you set the DST flag to >0 "Daylight saving time is in effect".

I have an application that writes some time information to file, then reads it in to do some things then write it all out again.

If my program is being run at 8:00 on the 5th of August 2012, and it reads from the file "15:30 1st Jan 2012", what exactly does the DST flag do?

I will read from the file a string that holds the information "15:30 1st January 2012" and convert that all into numbers so I have

hours: 15
minutes: 30
days: 1
months: 1 (although it could be 0...)
years: 2012 (or with any defined offset)

Then I call the CTime constructor and shove that all in to get a CTime object in local time, but will that be 15:30 because it says so, or 14:30 because it's run in August?

===============

I'd love to get my work done having understood what CTime does, but what I really need to figure out is a way of writing out to file in UTC then reading that back in UTC, but from what I can tell, if I use CTime, it will convert whatever I put into into local time.

Hence, at the moment, I've got a program that back tracks through time by 8 hours every time it runs (I'm in Japan).

Please help!

Thanks in advance.

Posted 19-Jun-12 21:31pm

PaulowniaK

Add a Solution

3 solutions

Solution 2

You may store the values in the standardized ISO-8601 [^] format:
[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss]Z.
This format is supported by most date/time from string parsers. The date/time separator 'T' is often replaced by a space character for human readability (this will break the standard but is widely accepted).

The 'Z' (Zulu) character at the end indicates UTC here. As already noted by Richard, storing as UTC is always preferred.

Posted 19-Jun-12 23:11pm

Jochen Arndt

Comments

Richard MacCutchan 20-Jun-12 9:09am

Good suggestion.

Solution 3

To answer your original question: Then I call the CTime constructor and shove that all in to get a CTime object in local time, but will that be 15:30 because it says so, or 14:30 because it's run in August?

If you set the nDST parameter to a negative value (the dafault), CTime will figure out whether on that date in August (and that time) DST will apply and convert your local time according into UTC. It you set nDST to 0, CTime will take it for granted that this time stamp was taken at a time with no DST and hence convert it back to UTC accordingly. If you set nDST to 1, CTime will take it for granted that the timestamp was taken while DST was in effect and convert accordingly.

Note that CTime looks at the current locale settings to figure out in which time zone you are and find out the corresponding correction value. In case of nDST < 0 it will also consult the locale information to find out which rule applies for determining if a timestamp falls into the DST period.

The nDst parameter hence gives you a little more control over whether the DST correction is applied, for example in cases in the past for which different DST rules might have applied. If you can determine from your text-based representation of a timestamp if DST was in effect at that time, I would always use that information instead of using the default nDst = -1.

Posted 20-Jun-12 0:21am

nv3

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Richard MacCutchan · Accepted Answer · 2012-06-19T21:46:00

Solution 1

The answer is, never store times and/or dates as strings. The only valid way to track times correctly is always to store them as UTC values. That means the timestamp is an accurate representation of the real universal time that your event occurred and is correct forever. When you want to display the value for a user you can apply whatever timezone you wish, and get DST added automatically.

Posted 19-Jun-12 21:46pm

Richard MacCutchan

Comments

PaulowniaK 20-Jun-12 4:16am

Thanks for your suggestion. I agree with you, but I prefer to store the time as string so that service personnel can read the file in a text editor and make service related decisions. If the file is written in UTC then we will need a separate application for the service personnel.

Actually, I am well aware that writing the file in local time is stupid. If the PC containing the program travels half way around the earth and the PC clock is set to local time, who knows what'll happen when the program next runs.

What I'd really like to do is to write out the UTC in human readable form, then read it back in as UTC without applying any conversion. Is that possible?

[no name] 20-Jun-12 8:48am

I think you responded without thinking about the problem. The answer is correct and you need to understand time before you play with it. UTC is universal (even on the moon). From UTC you can get local time taking into account time offset and daylight saving. This makes UTC when correctly interpreted failsafe. There are a number of implementations of time but UTC is the reference.

PaulowniaK 20-Jun-12 20:19pm

Yes, I fully agree with you.

The problem I need to solve is that I don't seem to have full control of whether to convert to local time or not.

[no name] 20-Jun-12 21:57pm

Thats not true. You are in full control. Every programmer dealing with time has these issues to deal with. If you store as UTC (time_t for example) read it back and convert to local time this will give the correct time. So the steps are convert local time to UTC - store it - read it back and convert to local time. If you are losing or gaining time you have a bug.

PaulowniaK 20-Jun-12 22:08pm

>So the steps are convert local time to UTC - store it - read it back and convert to local time.

There's the problem.
I want to convert local time to UTC, store and read it back as UTC.

>you have a bug

You don't say!

[no name] 20-Jun-12 22:36pm

Well if stored as UTC it reads back as UTC - that is axiomatic. To display it just use asctime() as suggested below. As for the bug I suggest you post a code snippet.

Richard MacCutchan 21-Jun-12 3:02am

No, forget local time, it is an irrelevance. Capture all time stamps in UTC and save them as such. The only time you ever need any conversion is when you wish to display the time in human readable form, and that is when you apply the local timezone offset and convert into some printable format.

[no name] 21-Jun-12 4:44am

Well stated. My mistake - I was thinking about displaying the time at time of logging. Your summary applies to all cases.

Richard MacCutchan 21-Jun-12 4:58am

I had a similar argument with our System Architect on the last project I worked on, but she just could not understand the issue. I always find it odd with the Americans, who live in a land of multiple time zones, that they have so little understanding of how it works.

[no name] 21-Jun-12 5:10am

Have seen it many times. Regards.

Richard MacCutchan 21-Jun-12 5:00am

And by the way, I was not challenging your assertions, which are correct, just trying to get PaulowniaK to see how simple it is.

Richard MacCutchan 20-Jun-12 9:07am

Unless you store it as UTC you are most likely to have problems at some time; bite the bullet and do it properly. If you must write it as a string then use asctime() which does not adjust to local timezone.

PaulowniaK 20-Jun-12 20:19pm

Thanks, but it's the other way around.

I found a way to write out in UTC. I need a way to read UTC back into the program and keep it UTC.

Richard MacCutchan 21-Jun-12 2:59am

If you can write it out in UTC then you can read it back, it's the same value.