I have an application that runs on a device that is not connected to the internet. The OS is Windows XP. There're C++ module and Java module that interact over a socket. The Java part needs to get a file from the C++ part according to its date and time. When DST switch arrived they stopped working. It seems that the C++ ignores DST because Windows has not downloaded the yearly DST update, while Java handles DST according to some internal table it has. The device I'm programming has to be able to run continuously, disconnected from the net and in different countries. My question is: how can I make both Java and C++ ignore external updates and operate according to some pre-defined DST table.
A:
Do you have to use a time representation that is sensitive to DST? You could use Unix time (which is probably the one I would go with), TAI, or any other time-since-[some epoch] systems, and not have to worry about things like daylight savings or leap-seconds.
Todd Gardner
2009-05-24 06:24:36
Working with the representation of seconds since 1970 doesn't work for me.The C++ and the Java modules need to know when a day ends (the local time zone's day).
arsenalfan
2009-05-24 07:20:40
A:
I would suggest you use GMT+0 to record all date and only adjust the time when you display it.
Peter Lawrey
2009-05-24 11:18:00
+1
A:
Encode the date as a string which includes timezone information (ISO 8601 is the most complete standard for this). Use a good framework for parsing to/from the format on each side. Boost (C++) and Joda (Java) provide excellent support for this.
Epoch time will not work for you since it does not represent time zone.
If you need to adapt the timezone for doing centralized work with it then standardize on UTC, and allow the client to adapt the date/time to its locale for display purposes or for local manipulations. Otherwise just store/retrieve the date/time in the local timezone if all manipulations and display are done in the local timezone.
eqbridges
2009-05-24 14:04:45
Yes. I guess setting the time zone to UTC is good enough.Both sides will be in sync. The clock may be set manually to match the current time.
arsenalfan
2009-05-25 13:58:16
btw, there's no real reason to force it to be UTC if you're using a good framework for conversions. if it ends up being easier or more pragmatic to use 'server-local' time as your standard that can be an acceptable substitute for UTC. Decide based on your local setup and your requirements.
eqbridges
2009-05-26 13:16:25