× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Mike,

Thanks Scott. Won't this convert the Unix time to a timestamp based
on the current date not the date in the unix timestamp?

The date & time will be the same date & time that are in the Unix timestamp. However, the UTC offset will be based on the current UTC offset, and not what the offset might've been when the timestamp was created.

This is the way that Unix timestamps are normally dealt with. The idea is to separate the actual date & time from the time zone. You keep track of the actual date & time in a timestamp-neutral manner, and you display them in the user's current frame-of-mind (which is the user's local time zone.)

I've been programming in a Unix environment for a long time, and 99 times out of 100, that's what you do... you use the CURRENT time zone to represent the date/time.

That way, if you use users in Uruguay and users in Colorado, both will see the time in their own time zone, and can say "ahh, that time was 1 hour ago". (or whatever)

The other, much less frequent, part comes when you want to adjust the date/time for the daylight savings time (or summer time) offset that the date was (or will be) in. For example, if you want to say "Your account will expire at 3:00 on Dec 14, 2007" then it's important to adjust for the actual daylight/summer time setting that will be in effect on December 14. In my experience, it's relatively rare that something like this is needed, since usually you have something that expires on a given DATE, and not necessarily at a particular time. The 1 hour difference is usually negligible.

If this is an expiration date that the computer will deal with, you're better off keeping things in UTC and never converting them. If it's for a user to read and it'll be printed in advance, then it makes sense to adjust it for the DST setting, but in my 15 years of Unix programming, I've only had to deal with that once.

I guess you could convert it to a timestamp in the UTC zone, and use the QWCCVTDT API to convert it.

The localtime() routine in ILE C might work as well... though, I've seen this work differently on different platforms, and I haven't used it on i5/OS yet, so YMMV.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.